当前页面: 开发资料首页 → Java 专题 → J2EE vs .NET：赛前称重

J2EE vs .NET：赛前称重

摘要: J2EE vs .NET：赛前称重

“weigh in”这个词是指拳击赛之前两名拳手量体重的过程。在职业拳赛中，拳手和经纪人总会利用称体重的机会大肆向媒体张扬，展示自己的强悍。用这个词来描述J2EE和.NET在服务器市场上的竞争，可谓精当。
Java和.NET的口水仗似乎永无宁日，但实际上很多大公司同时支持这两个平台。这场“战争”，在一定程度上已经变成了市场炒作。这就像职业拳击赛，以赛前称体重为代表的作秀有时比战斗本身更加耐人回味。
我们可以给J2EE和.NET下一个简单的评语：J2EE功能更丰富；.NET使用更简单。同时，双方又都在向对方取长补短。两个平台的差异早已不像他们刻意鼓吹的那么悬殊。
IBM开发出了一整套的IDE技术，大大简化了J2EE应用的开发过程。IBM把主要的IDE技术捐献给了开放源码的Eclipse项目，更多开源人群的参与将给J2EE开发者带来更大的便利。一些观察家提出，简化J2EE开发的一条捷径就是使用J2EE中较为简单的部分，尽量放弃其中复杂的部分——尤其是EJB。开放源码的JBoss应用服务器正是这样做的，而且似乎效果很好。在很多时候，一个Tomcat的应用服务器就足以解决所有的问题了。
同时，微软也宣称.NET在“功能丰富”的方向上取得了长足进步。
对于ISV来说，平台的选择通常不是由兴趣来决定的。如果需要兼顾Linux和Unix平台，J2EE通常是他们的唯一选择。另外，J2EE承继了大型主机和Unix的风格，各个部件之间相对松散独立，需要一定的组合过程；而.NET的风格则更像AS/400和Windows NT，所有东西都紧密集成在一起。这种风格（或者叫文化）上的差异也会影响企业的选择。
一般认为，Visual Studio .NET提供了大量的向导，因此相对容易使用，开发速度也较快。但在面临大范围、高复杂度的应用时，就显得有些力不从心。对.NET平台进行定制的难度也更大，微软希望你在他们限定的范围内玩。
Gartner的分析数据显示，操作系统正在逐渐失去软件业的霸主地位。预计到2007年，集成服务器、应用服务器、Web服务器、集群软件等企业级服务器软件的收入将超过服务器操作系统。从这个数据不难明白，为什么微软要不断地推广.NET的“服务”理念，为什么Sun要在J2EE中加入越来越多应用服务器的功能。
所以，J2EE和.NET仍然在打着口水仗，并继续向对方学习。双方的技术很快将（甚至可能是已经）达到登峰造极的地步，于是双方在技术指标上的差异将小到可以忽略不计的地步。毕竟，两者都采用虚拟机技术，两者都处理同样的三类I/O（前端HTTP、进程内通信、后端数据库），有理由相信两者都会把这些技术发展到极致。
感谢自由和竞争的市场，让我们能够拥有“选择的痛苦”。
全文请看：
http://www.adtmag.com/article.asp?id=7610
相关连接：
Java开发环境瞄准前端建模市场
Windows Server 2003上市
作者相关文章： 2003，JavaOne会办成什么样子？(原作) 地域为何消失——解读《消失的地域：电子媒介对社会行为的影响》(原作) 品味经典——书评《人工智能哲学》(原作)
对该文的评论人气：1187 kiki12(2003-5-4 18:53:17)
如果采用了.net,ORAClE/DB2/MySQL数据库，Unix/linux操作系统以及在在上面运行的各种软件,lotus notes群件/iplanet目录服务器/Apache 服务器等等全要完蛋.......中国人，不要人云亦云，多思考思考，等你们弄明白什么叫.net,什么叫J2EE再说.....忘记了,Coraba也要完了
mobilephone(2003-5-4 17:12:28)
其实用什么不是程序员可以决定的，是需求决定的。所以，什么J2EE、NET之类的技术，不过是给大家一个学习的机会和方向，关键是不是可以从中获取对软件开发的新认识。还是那句话，本质是最重要的。
jdbc_ejb(2003-5-4 15:27:36)
jdo是发展方向，这绝对没有错....不过用Jbuilder开发EJB还是相当容易的，其中是产生了大量的垃圾代码....
rocandroc(2003-5-4 14:03:32)
以前总是认为初学者总是喜欢争论java和.net的好坏。总是会提出到底应该是学java还是.net的问题。看来仅仅如此啊：) 还是那句话。 .net还没有成熟。
ossa(2003-5-4 13:59:39)
在我用了n年ejb后，得到了一个很悲伤的结论： ejb是垃圾，是阴谋（为了提高j2ee提供商的门槛，或调衡几个大厂商的利益） 1.EntityBean比关系对象映射（如jdo）概念更复杂，难以实现，难以部署，性能也更低； 2.有了连接池，无状态session bean的对象池的已经没有任何优越性（会节省1%的内存？） 3.有状态session bean也许有用，但为了更大的扩展性，我们宁愿把回话信息保存在servlet的session中或客户端。现在jboss起来了，sun,bea,ibm,oracle都慌了..., j2ee确实不错,但ejb是垃圾！！！
miwoo(2003-5-4 13:12:02)
抛弃EntityBean,采用JDO!
dickmi(2003-5-4 13:05:58)
EJB是不难，可是大量的J2EE部署配置，和大量无聊代码，的确非常需要工具。
jdbc_ejb(2003-5-4 11:35:23)
EJB根本就不难,很好理解~~~~~~~~~~~~~~~~~~~~~
dujianyong(2003-5-4 9:41:22)
在面临大范围、高复杂度的应用时，就显得有些力不从心。举例啊！
dujianyong(2003-5-4 9:39:19)
尽量放弃其中复杂的部分——尤其是EJB,那j2ee还有什么啊？
↑返回目录
前一篇: J2EE Web组件中中文及相关的问题（二）
后一篇: J2EE vs .NET (2)