Java不该转换至.Net的五大理由

[yanglilibaobao]

.Net Framework号称是分布式运算产业的下一波重点。
　　
　　由于是全新设计，微软这项技术在部分领域上显然有明显进步，如XML整合、错误处理、组件处理，和可重复使用的架构等方面。Web开发的未来十分明确：更快的开发、程序可少写一些、稳定性会更好。
　　但是如果你目前的应用软件是用Java EJB(Enterprise JavaBeans)写出来的呢？将这些软件移植到微软新平台值得吗？.Net与Java EJB哪一个比较优秀的话题未来一定还有得吵上一阵子，但这类平台转移的困难度却比较容易预测。即使你有非常迫切的技术或商业原因必须作转换，以下还是有五大理由奉劝你不要轻言将Java或J2EE程序转到.Net平台上。
　　
　　1. CLR不支持Java
　　转移至.Net的第一个障碍就是它所支持语言。.Net架构是靠着Common Language Runtime (CLR)来实现多语言的兼容性，但是这个兼容性目前只限于C#、C++、VB和(即将加入的)J# 。而一点也不令人意外的是，Java并非CLR所支持的程序语言。
　　要将Java应用程序转移至.Net但又无须以CLR支持的语言重新撰写程序的确是有可能，只需透过Java COM转换程序或Web services(网络服务)即可。然而，Java COM却需依赖第三方软件才能从Java程序代码建立COM DLLs。但这方面在尔后的除错过程会相当困难，同时也增加了环境的复杂度，因此要处理这类异质应用开发必须非常小心，甚至建议不要采用。
　　另一种策略就是将Java程序代码转换为C#程序代码。理论上，你可以利用自动化程序将Java码直接转成C# (与J#)语言。例如，ArtinSoft公司的Java Language Conversion Assistant Enterprise Edition (JLCA EE)号称可将Java转成C#语言，正确率高达99%，但这样的产品还没有经过市场验证，且经验法则也会告诉你最好不要信任自动转码机制。不管是使用自动转码方式还是透过手动，语言转换总会涉及架构转变的问题。当你将Java程序改成VB、C++、C#或J# 后，程序中也将会有许多地方必须重新调整(依据应用程序的设置规格而定)。
　　服务器控制太麻烦
　　2. IIS不支持JSP
　　若你认为只要将程序语言从Java改成C#就大功告成，那就错了，.Net还会要求连同呈现(presentation)语言也要一起转换，IIS并不支持JSP。从JSP转换成ASP.Net绝对是一项大工程，且你必须完全重写presentation层不可。另外，许多重要的架构模式在ASP.Net下也不支持，例如透过卷标库的程序代码再利用即是一例。卷标库必须转换成服务器控制或是服务器端的includes(ssi)。有意思的是，支持卷标库的Java classes在概念上正好与.Net的程序代码后置(code-behind)classes相当，但实际转换还是需要花上许多功夫。
　　
　　
　　3.服务器控制需要重新设计
　　之前提过，在对.Net的程序代码进行语言转换时，新的架构需求一定也会跟着浮现。这在计画.Net服务器控件(server controls)的实作时更是明显。ASP.Net服务器控件是.Net的最大优势之一。开发人员可利用预先建立的服务器组件，降低重复性的程序撰写，且可轻松透过对象存取各项功能。若希望转换成.Net平台后也能使用服务器控件的好处，你势必要移除许多客制化的呈现层、应用程序与数据库程序代码，并全部改成服务器控件以及所需的数据库逻辑。
　　若你是从既有的微软应用程序作升级，此一程序代码的抽取(extraction)并不困难，特别是之前你有良好的程序撰写习惯的话(分割明朗，条理分明)。然而若是从Java EJB程序作升级时，服务器控件则会动到非常深入的垂直转换，同时将影响到资料、应用程序、以及程序的呈现层。所有之前储存的程序、Java对象，和JSP文件都必须转换成微软支持的标准，同时还需经过修改才能支持Server Control。
　　例如，DataGrid对象可复杂的表格功能来呈现资料记录。部分可由使用者自行控制的选项包括行列选择、头标样式以及呼叫(paging)功能等。DataGrid对象比任何客制化或是专属程序代码的功能都更强大、维护也更容易。但若Java应用程序转换后（假设你要从Oracle资料层转往SQL Server），要利用此一控制选项的话，你需要：
　　‧将P/L SQL重写成Transact SQL，并将查询重新格式化以支持DataGrid。
　　‧将Java程序代码改成.Net所支持的语言以便取出SQL或预存程序，并支持DataGrid的事件模型。
　　‧移除支持现有客制化的呈现对象，并将JSP模板重写成ASP.Net。
　　从头至尾 困难重重
　　4.不支持CMP容器管理永续性
　　假设现有的Java程序是由非SQL Server数据库所支持，那么移植应用程序之后，你还得同时将数据库转移至SQL Server上，或者安装驱动程序好让.Net应用程序能经由非SQL Server数据库保持资料持续性。不管哪一种情况，你都必须将JDBC连接类改写成ADO.Net，并将Java ResultSets移植到ADO.Net DataSets。这项工作本身并不特别困难，DataSets和ResultSets具有相似的机制，除了实作规格外并不需要动用到架构重建。
　　不过当开发团队将对象永续(object persistence)从Java转换到.Net时，问题就会开始出现。.Net并不支持Container Managed Persistence (CMP：容器管理永续性)，也没有类似的机制。如果你的程序是靠着CMP来保持对象的永续性，你就必须以内嵌式逻辑重写撰写对象类别才能进行资料撷取与加载。
　　5.不同的session处理实作
　　EJB标准并不指定session资料的处理，所以EJB session处理实作变成完全与应用服务器有关。由于在不同的session处理实作攸关性能表现、扩充性与网络设计，因此你必须对应用软件中的session-handling机制细节有完全的了解。
　　在.Net之中，微软则采用一种分布式session模型，它通过Microsoft SQL Server存储应用软件的状态，使得session资料同时分配给同一网络机房中的多个应用软件服务器。由于.Net依靠SQL Server中的内嵌功能来做session，因此使用Oracle或是其它非SQL服务器数据库的不同类型应用软件，都必须建置一个SQL Server instance只为了当作分布式sessions之用。此外，由于大量的session资料将会降低系统总体性能，因此session储存也必须谨慎使用。
　　
　　
　　转移难度高 成效顶多平手
　　.Net Framework代表着微软进军高可用度、企业级应用程序领域的最新成果。以往在IIS、Visual Studio、VB和SQL Server中所缺乏的功能都可在新平台上找得到。微软的开发者和用户现在终于不会矮人一截，不论在扩充性、沿展性、安全与性能上都可与业界对手平起平坐。
　　关键问题是，.Net与EJB解决方案供货商之间顶多打成平手，没有任何迹象显示.Net平台优于WebSphere、WebLogic、或任何其它EJB应用软件服务器。对于既有的IIS/ASP解决方案，转移平台的效益再也明显不过。而对于从头开始的新计画，.Net也可算是架构平台的一时之选(端视员工技能与企业偏好)。但是对于既有Java EJB应用软件而言，一动不如一静，因为即使你辛苦地转换了老半天，到头来发现两者其实并无差异。
　　
　　
　http://www.linuxmine.com/47601.html　Godfrey Baker原著

[jk88811]

原来是说Java应用不知道转为.NET

我以为是说人呢。。。

Java跨平台，.NET则不行，这就是最大的理由...

[galant2008]

就因為叫java,所以不能

[十分钟年华老去]

好多分

[alex_homer]

java优雅！就这样~~~~~~接~~~接分！！

[qq9518]

在电子商务解决方案上,.NET并不次于JAVA,据说MS是因为打官司/发展2K而耽误了.NET各个方面的成长,JAVA对于.NET来说最大的好处在于跨平台,而其他的,都没什么可比性,各有千秋.不能说JAVA绝对得好,或.NET绝对得坏,我觉得.NET也不错.(在读学生愚见)

[wfyfngu]

很片面！
>>> 1. CLR不支持Java
可是支持J#，当然，在dotNET平台，估计找不到人使用J#作为开发语言
>>> 2. IIS不支持JSP
IIS是一个服务器，和Apache一样，它不支持jsp是因为它没有jsp脚本解析器，就象如果没有php解析器或asp解析器就同样不能运行php和asp一样。要让IIS支持jsp，只要添加一个jsp解析器并做好脚本映射就可以了
>>> 3.服务器控制需要重新设计
服务器控件是dotNET平台的特性，是java没有的。谈何“重新设计”
>>> 4.不支持CMP容器管理永续性
没有人说使用asp.net就非得用SqlServer做数据库服务器，事实上、只是asp.net对SqlServer具有最良好得支持。它同样支持Oracle、MySql和其它所有ODBC数据库，甚至是Excel和普通的文本文件
>>> 5.不同的session处理实作
确实！但是asp.net下的session并不只有依靠SqlServer才能工作。而且，就算必须依靠SqlServer，只要转换后的代码正确，你管它的工作机制呢。而事实上，jsp的session机制非常复杂，就是做jsp也完全不需要去了解它的工作机制


其实，整个言论都是无稽之谈
而且显然对dotNET平台的认知很肤浅
以至于出现很多低级的错误
也没有人会s到把一个j2EE程序转到dotNET下面
因为完全没有那个必要

[wsb_8224]

顶!

[dongdong715]

妈的 恶心

[haisenmai]

顶!

[asd_]

几个菜鸟在这里做梦呢，我的建议，能转.net，转c/c++的赶紧转，让sun自己去瞎折腾吧。

1. CLR不支持Java
------------
clr凭什么要支持java?有c#有web services框架，再支持java不是有病么？

2. IIS不支持JSP
------------
同样的道理，IIS凭什么要支持jsp?iis做好自己的事，留下了给apache,tomcat的接口就好了。
只有在jcp脑子进水的人才想到大而全这样的混蛋主意。

3.服务器控制需要重新设计
-----------
拜托，别人为什么要这么做？凭什么要这么设计？不要照搬jcp的那点教条。

4.不支持CMP容器管理永续性
-----------
你说jconnector框架还有点新意，cmp并不怎么样，不是说它不轻量级，而是确实不怎么样。

5.不同的session处理实作
-----------
知道session是什么吗？这水平是给台湾的javaer丢脸。

整个一不知所云。

[asd_]

j#不是java,而是一种类java语言，因为其运行原理完全不同于java

[wsb_8224]

顶!

[manlikeme]

我刚做了一年.NET然后转过来做java了.我觉得.NET好,基本实现简单,高深的没有研究过.以前觉得java好可怕,现在接触了,也就那么回事,jsp.servlet,ejb,oracle,weblogic.用起来也挺简单的(接触不多),但是我们系统里javascript但是很可怕每个页面都需要上千行啊.不过做java有一个好处工资高..NET实现起来容易,java工资高我觉得就这些区别.哈哈

[luoyw]

呵呵,是吗?

[ZiRRen]

我也是他妈的弄了快一年的.net了,现在经理要让20天学会java.Hibernate,spring jsf.还有什么jsp servlet等,学了两天了,真他妈的怀念.net的日子.

操.

[dadi0189]

java？呵呵，