是否可以接受在ASP.NET代码隐藏页中使用多种语言?

你应该记住三点:

1. 如果它没坏,就别修了。
2. 团队构成和熟练程度
3. 编码标准和一致性

首先,就像许多人所说的,如果代码没有被破坏,那么为什么还要努力修改代码库呢?在语言转换期间,您有可能添加错误,即使它们都是在ASP.NET中运行的.NET语言。

第二,我假设有一个合理的理由来分叉这个项目并使用vb.net,而不是继续使用c。这种语言变化的原因是什么?这些理由不再有效了吗?考虑导致分叉到另一种语言的假设的有效性。

第三,所有团队成员是否都能胜任C?如果有几个团队成员不精通C的话,将所有代码迁移到C可能是一个负担。

最后,我建议采用编码标准,并从这一点开始将所有新的开发集中在一种语言中。除了这些标准之外,您还可以考虑一个策略,即如果需要修改/修复vb.net页面,则应将此页面迁移到c_。

在这一点上,vb.net页面不再是“未损坏”的,您很可能需要通过调试/测试阶段来验证修复/更改。所以你要把迁移的成本加到任何错误修复上。通过这种方式,您可以慢慢地将代码迁移到C,而不会产生很大的一次性成本。

如果您不愿意为迁移一个页面以及VB.NET页面中的任何错误修复或更改而付出代价,那么请注意这一点。您很可能没有时间或资源来迁移所有的vb.net页面。由于大规模迁移需要更多的时间,因此在迁移过程中,明智地要求您停止vb.net页面上的所有工作/修复。这可能是一个关于迁移到C是否是一个考虑到您的业务需求的选项的指标。

你的建议是部分重写。

我只能在现有代码的功能或体系结构出现严重错误时提倡重写。

相对于vb,对c的偏好还不够合理。

你可能不想这样做。 在这种情况下,可维护性将是非常困难的,因为团队通常具有单一语言的专业知识。

我们在这里有一些项目使用为某些页面编写的C,为其他页面编写的VB.NET。 建立团队来维护这样的项目是困难的。

亲切的问候, 阿施施

要回答第一个问题,是的,这是完全可以接受的,并且得到了微软的支持。

你应该换一下吗?如果您的开发人员了解项目情况,那么我认为您是不是很好,但是如果您开始发现NAMSpace、引用或开发团队无法处理VB的问题(不太可能)。然后我会考虑重新写作。

但是,如果代码在那里并且在工作,那么通常很难证明重新编写代码是正确的。

它得到了很好的支持。

对于页面来说没有什么区别。每一页都是单独编译的。

对于app_code目录中的代码,它是基于每个文件夹编译的。因此,c文件和vb.net文件需要放在各自独立的子文件夹中。这些子文件夹需要在web.config的编译部分中注明,以便编译器知道如何对它们进行不同的处理。

<configuration>
<system.web>
    <compilation>
        <codeSubDirectories>
            <add directoryName="VB_Code"/>
            <add directoryName="CS_Code"/>
        </codeSubDirectories>
    </compilation>
</system.web>

这里有一个不错的链接。 Using VB.NET and C# in the App_Code folder

我发现的唯一缺点是IntelliSense似乎无法在两个子应用程序代码之间工作。不过,在页面中,IntelliSense工作正常。