五个反对向.NET移植Java EJB应用软件的理由

核心提示：五个反对向.NET移植java EJB应用软件的理由 .NET架构已经被吹捧为分布式计算业界的又一个重大的事件，通过重新设计，五个反对向.NET移植Java EJB应用软件的理由，微软在xml整合、错误处理、部件处理和可重用架构等方面有了显著的进步，Web开发的前景十分的明确：更快的开发，Da

　　五个反对向.NET移植java EJB应用软件的理由

.NET架构已经被吹捧为分布式计算业界的又一个重大的事件。通过重新设计，微软在xml整合、错误处理、部件处理和可重用架构等方面有了显著的进步。Web开发的前景十分的明确：更快的开发，较少的自定义编码和稳定性的增强。

但是假如你目前的应用软件是一个Java EJB应用的话会怎么样呢？值得付出时间和金钱向微软的新型平台进行移植吗？当.NET通过Java EJB所能获得的收益这一问题会在未来几年中继续被争论时，这样的平台接口中所涉及的难点却更轻易预料一些。即使有着重要的技术或商业原因在促使这方面的需要，这里还是有五个反对向.NET移植Java或J2EE应用软件的理由。

1. CLR并不支持Java

向.NET移植的第一个障碍就是它对所支持语言的设置。.NET架构是依靠Common Language Runtime (CLR)来实现多语言的兼容性，但是这个兼容性目前只限于C#, C++, VB和J# 。所以，Java并不被CLR所支持是很正常的。

通过使用Java COM或是Web服务，将Java应用软件层向.NET移植而不需要用CLR所支持的语言重新编写应用软件代码将会是可能的。然而，Java COM依靠于第三方应用软件来直接从纯Java代码中创建COM DLLs。调试结果二进制编码的困难，还有复杂性的增加，都说明了为什么在进行这种应用软件开发时要谨慎行事，要不然就彻底地避开它。

另一种策略就是将你的Java代码导向C# 代码。理论上，你可以通过自动化的应用程序将Java代码直接翻译成C# (还有J#)。例如，ArtinSoft的Java Language Conversion Assistant EnterPRise Edition (JLCA EE)承诺了百分之九十九的从Java到C#的自动转换，但是这样的产品还没有在市场上被证实，而且有人争论要不要相信这种自动代码转换。不管是使用自动化的处理方式还是通过人工来进行，这种转换都毫无疑问地需要有相关的体系架构上的改变。当将一个Java应用程序重新编写成VB, C++, C# 或J# 时，可能就需要进行大量的再分解工作，这取决于你的应用软件的具体设定。

2. IIS并不支持jsp

就似乎将一个应用程序的语言端口从Java转换为C# 还不够麻烦似的，.NET还需要有一个表示语言端口。而JSP并不被IIS所支持。从JSP转向asp.net是意义重大的一件事，它将需要对表示层彻底的重新编写。还有大型架构模型，例如通过标签库的代码再利用，并不被ASP.NET所支持。标签库必须被转换至服务器控制或是服务器端包含内容(ssi)。有意思的是，支持标签库的Java类正好与.NET的代码之后的类相匹配，但是实际的转换之中还需要大量的工作。

3.服务器需要重新设计

前面提到了，在对.NET的代码进行语言的重新编写时必然需要有新的体系结构。假如.NET服务器控制的执行已经做出计划，这就会变成非常的明显。ASP.NET服务器控制是.NET所提供的最大的优势之一。通过利用预建构的服务器部件，开发者可以减少重复性编码并轻松地通过对象访问函数功能。在向.NET移植的过程中利用服务器控制的优势将可以实现自定义presentation，应用程序和数据库代码的去除并取而代之以服务器控制和所要求的数据库逻辑。

当从一个现有的微软公司应用软件进行升级时，这个代码的解压缩并不困难，非凡是在由良好的编程习惯带来的划分清楚和组织良好的代码时。然而，当从一个Java EJB应用软件升级时，服务器控制则要求垂直纵深的移植，且可能同时地影响到应用软件的数据，应用程序和presentation层。存储程序，Java对象和JSP文件不仅是需要改为微软支持标准，他们还需要通过修改来支持Server Control。

例如，DataGrid对象提供了综合的表格功能来显示一整套数据记录。行和列选项，标题风格和分页功能只是客制化的属性中的一小部分。DataGrid对象比任何客制化或是私有化代码都更具有功能性和可维持性。在从Java应用软件升级时（假设你将一个Oracle数据层移向SQL服务器），要利用这种控制的优势，你需要：