如何开发出一个高质量的J2EE(转载)

　J2EE学习者越来越多，J2EE本身技术不断在发展，涌现出各种概念，本文章试图从一种容易理解的角度对这些概念向初学者进行解释，以便掌握学习J2EE学习方向。

　　首先我们需要知道Java和J2EE是两个不同概念，Java不只是指一种语言，已经代表与微软不同的另外一个巨大阵营，所以Java有时是指一种软件系统的流派，当然目

前主要是.NET和Java两大主流体系。

　　J2EE可以说指Java在数据库信息系统上实现，数据库信息系统从早期的dBase、到Delphi/VB等C/S结构，发展到B/S（Browser浏览器/Server服务器）结构，而J2EE主要是

指B/S结构的实现。

　　J2EE又是一种框架和标准，框架类似API、库的概念，但是要超出它们。如果需要详细了解框架，可先从设计模式开始学习。

　　J2EE是一个虚的大的概念，J2EE标准主要有三种子技术标准：WEB技术、EJB技术和JMS，谈到J2EE应该说最终要落实到这三个子概念上。

　　这三种技术的每个技术在应用时都涉及两个部分：容器部分和应用部分，Web容器也是指Jsp/Servlet容器，你如果要开发一个Web应用，无论是编译或运行，都必须要

有Jsp/Servlet库或API支持（除了JDK/J2SE以外）。

　　Web技术中除了Jsp/Servlet技术外，还需要JavaBeans或Java Class实现一些功能或者包装携带数据，所以Web技术最初裸体简称为Jsp/Servlet+JavaBeans系统。

　　谈到JavaBeans技术，就涉及到组件构件技术（component），这是Java的核心基础部分，很多软件设计概念（设计模式）都是通过JavaBeans实现的。

　　JavaBeans不属于J2EE概念范畴中，如果一个JavaBeans对象被Web技术（也就是Jsp/Servlet）调用，那么JavaBeans就运行在J2EE的Web容器中；如果它被EJB调用，它就

运行在EJB容器中。

　　EJB（企业JavaBeans）是普通JavaBeans的一种提升和规范，因为企业信息系统开发中需要一个可伸缩的性能和事务、安全机制，这样能保证企业系统平滑发展，而不

是发展到一种规模重新更换一套软件系统。

　　至此，JavaBeans组件发展到EJB后，并不是说以前的那种JavaBeans形式就消失了，这就自然形成了两种JavaBeans技术：EJB和POJO，POJO完全不同于EJB概念，指的

是普通JavaBeans，而且这个JavaBeans不依附某种框架，或者干脆可以说：这个JavaBeans是你为这个应用程序单独开发创建的。

　　J2EE应用系统开发工具有很多：如JBuilder、Eclipse等，这些IDE首先是Java开发工具，也就是说，它们首要基本功能是可以开发出JavaBeans或Java class，但是如果要开

发出J2EE系统，就要落实到要么是Web技术或EJB技术，那么就有可能要一些专门模块功能(如eclipse需要lomboz插件)，最重要的是，因为J2EE系统区分为容器和应用两个部

分，所以，在任何开发工具中开发J2EE都需要指定J2EE容器。

　　J2EE容器分为WEB容器和EJB容器，Tomcat/Resin是Web容器；JBoss是EJB容器+Web容器等，其中Web容器直接使用Tomcat实现的。所以你开发的Web应用程序可以在上

面两种容器运行，而你开发的Web+EJB应用则只可以在JBoss服务器上运行，商业产品Websphere/Weblogic等和JBoss属于同一种性质。

　　J2EE容器也称为J2EE服务器，大部分时它们概念是一致的。

　　如果你的J2EE应用系统的数据库连接是通过JNDI获得，也就是说是从容器中获得，那么你的J2EE应用系统基本与数据库无关，如果你在你的J2EE应用系统耦合了数据

库JDBC驱动的配置，那么你的J2EE应用系统就有数据库概念色彩，作为一个成熟需要推广的J2EE应用系统，不推荐和具体数据库耦合，当然这其中如何保证J2EE应用系统

运行性能又是体现你的设计水平了。

　　衡量J2EE应用系统设计开发水平高低的标准就是：解耦性；你的应用系统各个功能是否能够彻底脱离？是否不相互依赖，也只有这样，才能体现可维护性、可拓展

性的软件设计目标。

　　为了达到这个目的，诞生各种框架概念，J2EE框架标准将一个系统划分为WEB和EJB主要部分，当然我们有时不是以这个具体技术区分，而是从设计上抽象为表现层

、服务层和持久层，这三个层次从一个高度将J2EE分离开来，实现解耦目的。

　　因此，我们实际编程中，也要将自己的功能向这三个层次上靠，做到大方向清楚，泾渭分明，但是没有技术上约束限制要做到这点是很不容易的，因此我们还是必

须借助J2EE具体技术来实现，这时，你可以使用EJB规范实现服务层和持久层，Web技术实现表现层；

　　EJB为什么能将服务层从Jsp/Servlet手中分离出来，因为它对JavaBeans编码有强制的约束，现在有一种对JavaBeans弱约束，使用Ioc模式实现的（当然EJB 3.0也采取这种

方式），在Ioc模式诞生前，一般都是通过工厂模式来对JavaBeans约束，形成一个服务层，这也是是Jive这样开源论坛设计原理之一。

　　由此，将服务层从表现层中分离出来目前有两种可选架构选择：管理普通JavaBeans（POJO）框架(如Spring、JdonFramework)以及管理EJB的EJB框架，因为EJB不只是框

架，还是标准，而标准可以扩展发展，所以，这两种区别将来是可能模糊，被纳入同一个标准了。　但是，个人认为：标准制定是为某个目的服务的，总要牺牲一些换

取另外一些，所以，这两种架构会长时间并存。

　　这两种架构分歧也曾经诞生一个新名词：完全POJO的系统也称为轻量级系统(lightweight)，其实这个名词本身就没有一个严格定义，更多是一个吸引人的招牌，轻量

是指容易学习容易使用吗？按照这个定义，其实轻量Spring等系统并不容易学习；而且EJB 3.0（依然叫EJB）以后的系统是否可称为轻量级了呢？

　　前面谈了服务层框架，使用服务层框架可以将JavaBeans从Jsp/Servlet中分离出来，而使用表现层框架则可以将Jsp中剩余的JavaBeans完全分离，这部分JavaBeans主要负

责显示相关，一般是通过标签库（taglib）实现，不同框架有不同自己的标签库，Struts是应用比较广泛的一种表现层框架。

　　这样，表现层和服务层的分离是通过两种框架达到目的，剩余的就是持久层框架了，通过持久层的框架将数据库存储从服务层中分离出来是其目的，持久层框架有

两种方向：直接自己编写JDBC等SQL语句（如iBatis）；使用O/R Mapping技术实现的Hibernate和JDO技术；当然还有EJB中的实体Bean技术。

　　持久层框架目前呈现百花齐放，各有优缺点的现状，所以正如表现层框架一样，目前没有一个框架被指定为标准框架，当然，表现层框架现在又出来了一个JSF，它

代表的页面组件概念是一个新的发展方向，但是复杂的实现让人有些忘而却步。

　　在所有这些J2EE技术中，虽然SUN公司发挥了很大的作用，不过总体来说：网络上有这样一个评价：SUN的理论天下无敌；SUN的产品用起来撞墙；对于初学者，特别

是那些试图通过或已经通过SUN认证的初学者，赶快摆脱SUN的阴影，立即开溜，使用开源领域的产品来实现自己的应用系统。

　　最后，你的J2EE应用系统如果采取上面提到的表现层、服务层和持久层的框架实现，基本你也可以在无需深刻掌握设计模式的情况下开发出一个高质量的应用系统

了。

　　还要注意的是: 开发出一个高质量的J2EE系统还需要正确的业务需求理解，那么域建模提供了一种比较切实可行的正确理解业务需求的方法，相关详细知识可从UML

角度结合理解。

　　当然，如果你想设计自己的行业框架，那么第一步从设计模式开始吧，因为设计模式提供你一个实现JavaBeans或类之间解耦参考实现方法，当你学会了系统基本单

元JavaBean或类之间解耦时，那么系统模块之间的解耦你就可能掌握，进而你就可以实现行业框架的提炼了，这又是另外一个发展方向了。

　　以上理念可以总结为一句话：
J2EE开发三件宝: Domain Model（域建模）、patterns（模式）和framework（框架）。
　　

  
 
Top  
 
 回复人： go_fan(木野狐) ( ) 信誉：100  2005-11-3 10:09:15  得分: 0  
 
 
   
初次涉及Java领域，感觉到Java入门是好像没有C,C++入门快，工具也没有什么Turbo C,Visual C++好用（自己的破机器实在陪不起JBuilder，贪婪的家伙，以后一定要收拾她

）。什么JAVA_HOME,CLASSPATH，虚拟机等概念都是初次基础，旁边的人都很少用Java的。感觉Java就是做Applet的。

慢慢的知道了http://java.sun.com，开始知道Java博大精深。让我不可思议的是JAVA 2,JDK,J2SE,J2EE,J2ME等新名词在自己的脑海里蔓延。慢慢的自己知道了JCP组织是制定

Java相关规范的发源地http://java.jcp.org ,于是订阅了一份邮件列表。真是好东西啊，定期有Java的最新动向，所以Java的动态尽收眼里，建议大家也去订阅一份。免费的。

自己动手下载了Java(TM) 2 SDK和Java(TM) 2 SDK Documentation后,不懂的就查Java(TM) 2 SDK Documentation,特别好用，也不需要什么手册之类的，建议大家都要有一份。

搭起Java开发环境后，记得还是用UltraEdit编辑并编译的（在其中可以配好Java的编译环境）。慢慢的改用JCreator了。不错，至少很多方面有改进。最开始卖了一套 2本书

，还不错。对于入门来说足够了。慢慢的知道是一本好书，后来才知道，有了Java经验后，看这本书特别过瘾，所以现在还经常翻翻。周而复始的看，效果特别好。

慢慢的知道了Oreilly公司（http://www.oreilly.com）出的图书不错，很高雅，国内翻译的也还可以（http://www.oreilly.com.cn）。本人收集了很多Oreilly的原版图书，有需要的

可以和我联系（Acrobat pdf格式）。慢慢知道了jjhou这个人.(http://jjhou.csdn.net )以及他的个人网站，最让我感兴趣的是jjhou老师写的散文，书评，很有收获，不是为技术而

技术。很有趣味性。其中, http://www.epubcn.com 上有很多美丽的图书。

不知道什么时候，要开始干项目了，以前从书上看到的东西，慢慢的在项目中有了很好的机会去温习，慢慢的有了感觉，开始主要是用Swing,开发桌面系统，放置一个

按钮怎么也放不好，后来才知道有一个布局管理器。咳，这个婆婆的Java也讨厌的很。开始涉及到数据库访问,JDBC。

后来我才知道，Sun的Java网站有一个Java Tutorial。（http://java.sun.com/docs/books/tutorial/ ）。同时，也知道了蔡??先生的sleepless in java

(http://www.oreilly.com.tw/sleepless/index.htm ),太美了，美的很。 满满的，OReilly, http://www.onjava.com/ 也是不错的地方。都有很多优秀的文章。http://www-

900.ibm.com/developerWorks/cn/index.shtml，也很棒。

每次，美美的享用一顿大餐后，也来也觉得自己是不是应该换一种学习方式，因为这样学习效果不太好。比较乱。让我想起了Java Specification，对，我开始研究Java规

范了。最开始下载的规范是JDBC Specification，很多概念一目了然，尤其是DATABASE的事务性控制，自己对于她的理解慢慢的有了较为深入的了解。对于开发C/S结构，比

如,Swing+JDBC,开发数据库应用系统，让我学会开发两层结构的应用系统。很神气。

也不知道什么时候要开始开发一个网站，基于Linux+JSP+JavaBean+Oracle的系统。很是有意思。为什么这么说呢？因为不同于Swing+JDBC的开发模式，系统之间多了一层

(JavaBean,姑且就这么叫吧！嘻嘻)；同时，很多开发技术和面向左面系统不一样，比如分页技术。

    完成项目后，自己对于Java的很多方面都比较了解了。开始思考一个问题，J2EE是什么东西？。我们学习Java大概有3个方向，第一，桌面系统，包括C/S结构；第二，

J2ME,面向无限领域，很有潜力的家伙，看看中国的手机用户就知道了。第三，面向企业应用、计算的平台,J2EE。

    在痛苦的抉择后，我选择J2EE..分享J2EE给我带来的快乐。学到现在，最大的感觉，就是: 简单就是美，美就是Java.不会有学MFC的痛苦，也不会有去分析STL的艰辛，网

路应用上一点也不逊色于C++。开始进入我的J2EE之旅。

    还是下载了一份J2EE规范，一份J2EE SDK。开始研究J2EE,结合http://java.sun.com/j2ee/tutorial/index.html提供的J2EE Tutorial开始研究了。大概过了1个月，开始有感觉了，也

就在这个时候，需要我去完成一个J2EE构架方面的项目。差不多边学编写完成了，很多概念在写完后都不是很清晰，因为东西太多了，主要是基于JSP(Servlet)+Session

Bean+EIS构架开发系统。当然也学到很多东西，至少对SB  EJB的编写不成问题。懂得了JSP如何调用EJB……。

    完成项目后，我开始研究Java Pet Store了，很是过瘾。开始知道了Servlet过滤器，XML方面较为全面的知识，知道了J2EE整个框架中各种技术的实际应用。慢慢的，开始

研究WebLogic配置好的Pet Store（也是Sun公司的）。慢慢的分析两者的不同之处。开始对J2EE Specification有了很好的感觉。因为J2EE Specification本身是很严肃的，但Pet

Store给出了活力。

    在反复的学习中，我明白了J2EE构架的70—80%。新的问题又出来了，实际企业中会如何建构一个J2EE系统呢？带着这个问题，我开始分析Core J2EE Patterns,这本书。同

时，也有EJB Design Patterns。慢慢的，开始知道了J2EE的魅力所在，知道了J2EE为什么会在企业中得到较为好的认可。大家都知道，设计模式一词，在公司上班，你们的

老板会看你的代码吗？会赞赏你的DP很好吗，我想很少。

    在完成你的工作进度之余，加班，加班，再加班，我想你没有更多的时间去分析研究DP.但，J2EE框架不一样，她内置了很多优秀的设计模式，我们在设计开发、构架

一个J2EE系统中用到了很多设计模式。比如，MVC,EJB中封装的DAO设计模式。构架J2E系统用Session Fa?ade,Message Fa?ade设计模式也不会太困难。这也是后来J2EE吸引我

的地方。

    慢慢的我知道了，作为一个J2EE开发者，我们要掌握其中的核心内容。我个人认为，3方面很重要。实施EJB系统常用的架构、设计模式，比如session fa?ade、message

fa?ade、DTO等。J2EE系统构架中常用的模式。UML-> EJB,EJB->UML相互映射。现在也一样在研究。

  
 
Top  
 
 回复人： go_fan(木野狐) ( ) 信誉：100  2005-11-3 10:17:14  得分: 0  
 
 
   
C#和.Net的初步研究 
ajumail发表于2005-03-21 
〔转贴自：CSDN〕

研究了一下C#和.Net，有很多体会，好的不好的都有。随便谈谈，供大家参考。

先说说它的优点：?

1、C#保留了对底层操作系统API的直接调用和指针。肯定是因为看到了Java的速度问题以及JNI的笨重，所以在设计C#时特意保留了这些C++的特性，避免了重导覆辙，也

使得C#可以用来开发系统软件。普通应用都是调用.Net的程序集(相当于Java的类库，程序集里面都是byte?code，不是native?code)，对于速度敏感，或者平台相关型应用，

直接通过特定声明来调用Windows?API。这样就可以功能，效率和速度都兼顾，解决各种各样的应用层问题和系统层问题(可以用C#来写系统软件了)，用一种语言来解决

所有场合的大部分问题，所以MS对C#很有信心。?

不过实际上完全用C#开发系统软件还是不太可能的，毕竟经过C#的包装以后，比纯种的C还是要稍微慢一些，但是肯定比纯种的C#字节码快太多了。但是当你用C#开发应

用软件的时候，却不可避免的涉及到底层调用的时候，可以方便的直接用C#来实现，不用像Java那样束手无策的去向C++求救，通过笨拙的JNI调用，显得高明。?

2、在Windows平台上.Net?CLR比Java的JRE速度快，联想到当年MS做的JVM，所以也不是很奇怪。只不过CLR速度足够快的话，C#字节码运行起来，普通应用就不会感觉出

来速度比纯本地代码慢。我的感觉就是这样，基本上感觉不出来CLR启动和加载程序集的明显延迟，而不管用AWT，Swing还是SWT，JVM启动和加载类库的延迟是非常明

显的，这就是真正不妙的地方了，不管Sun，IBM，BEA还是Open?Souce?社区，在JVM的效率上还要继续加油。?

3、开发工具IDE，老生常谈了，不过确实也很重要，对比一下Visual?.Net?Studio和做的最好的JavaIDE，JBuilder或者Eclipse吧，不在一个级别上。写普通的软件，甚至Web应

用，IDE作用不明显，特别是对于有Unix背景的人来说，更愿意使用纯文本工具。但是涉及到GUI开发和企业应用的开发，一个强大的工具是必须的。?

GUI开发来说，Visual?.Net?Studio开发GUI就如同使用VB开发GUI，方便和快捷的难以想像，再加上C#的程序集比VB的控件集，比VC的MFC的设计优秀的不在同一个级别上。

所以在开发GUI方面，C#比VB还更加优秀，基本上和Borland的C++?Builder的水平相当，其操作的便捷还在其之上。?

反观Java，Eclipse空有一个SWT，也不去做一个好点的GUI开发环境出来。JBuilder是公认的最好的Java?GUI开发IDE，但是仍然难用的很，为什么？关键处还在于AWT，

Swing和SWT图形库的布局设计上。?

这3个图形库统统都是使用布局管理器来布局，布局好了以后才能放控件。不能够直接拖放控件实现绝对像素定位，也很难实现对控件大小，位置的操纵。?

这也是有一定的原因，Java为了实现跨平台的GUI，因此不能够使用像素定位，否则在不同平台会有不同的外观表现。?

而C#就不管那么多了，既然只在Windows平台上实现，直接就采用像素定位(当然布局定位也可以用)，外观的控制自然可以“所见即所得”了。?

由于这个先天的原因，Java的GUI开发是不可能比C#更方便的，JBuilder能做到这样，也差不多到极致了，大家也只能忍受了。?

企业开发方面，C#需要SQL?Server(Oracle也可以，但是不如SQL?Server方便)，IIS和MTS的配合，Java需要DB，App?Server的配合。由于C#只管SQL?Server和IIS，甚至只管IE浏

览器，所以Visual?.Net?Studio可以做的很方便，整个开发过程一体化，不用考虑其它的实现。而JBuilder需要考虑各种不同的软件实现，特别是App?Server，简直就是五花

八门，JBuilder能够做到这样，在图形设计器里面设计EJB，从DB里面导入Entity?Bean，方便的在所有的主流的App?Server上自动编译EJB，部署EJB，测试EJB，也算做到极

致了。?

由于App?Server五花八门和EJB部署本身的高度复杂度的原因，Java的企业开发也是远远不如C#来的快捷和方便。?

这些原因导致了有时候一个J2EE项目会比.Net开发周期长两三倍的现象。?

说完了C#和.Net的优势，再说说不足：?

1、.Net平台支持多语言从技术上和开发角度来说是噱头，这完全是一个阴谋。?
从ISV角度来看，完全没有支持多语言的必要，难道做一个项目，不同的模块用不同的语言来实现有价值吗？反过来说，这是一个灾难。对于将来的维护的升级来说是一

个巨大的灾难，用VB.Net写的模块，C#程序员改不了，用C#写的模块，J#程序不能维护，人为的造成了混乱。再说C#又不是什么很难的东西，学习曲线也不高，何必不用

C#，非要和自己过不去呢？?

支持多语言的唯一目的在于吸引其它语言的开发人员转到.Net平台上来，不过当你被吸引转过来以后，还是发现用C#比较好，用你原来的移植语言不爽，还是不得不重新

学习C#，这才发现上了大当了。所以完全是一个商业阴谋。?

2、.Net在将来也不可能支持其它操作系统平台。?
在前面已经提到了.Net和IIS，MTS，SQL?Server等MS平台软件捆绑的很死，将来还要捆绑更多的MS软件，像IE，MSN等等。况且.Net依赖Windows也非常紧密。虽然有一个

Open?Source的Mono项目在移植CLR到Linux上来，不过据我来看，也只能做到仅此而已，光把CLR移植过来是没有多大价值的，需要把IIS，MTS，IE，MSN，SQL?Server等等

软件统统移植过来才能构成一个Linux平台上的.Net，但是这可能吗？?

所以MS开放C#语言和CLI的规范又是一个商业阴谋，表面上装出一副拥抱开放的姿态，骨子里面却垄断的很。而且从MS的商业行为也可以看出这一点，我们知道MS把全

部身家都压在.Net上和J2EE阵营竞争，如果.Net是一个开放平台，可以自由移植到Linux上，那么MS有什么理由不支持Linux操作系统呢？如果Linux上的.Net?支持的很好并且

普及开来的话，J2EE恐怕只有在AIX和Solaris上苟延残喘的份了。正是因为MS要把.Net锁定Windows，所以才害怕Linux，如果Linux在服务器市场击败了Windows，那么.Net也

只剩下苟延残喘的份了。所以现在MS视Linux为眼中钉，肉中刺。?

所以MS开放C#和CLI，除了做作姿态之外，也可以在更多的OS上普及C#编程的教学，等你们熟悉了C#编程，再乖乖的在我的Windows上替我开发吧。?

3、.Net傻瓜相机?
众所周知，C#和.Net的学习曲线比Java和J2EE平坦的太多了。C#学习比Java轻松很多，而.Net框架学习比J2EE轻松太多了。那么Java程序员投入多了几倍的时间和精力就完

全没有价值了吗？况且从开发角度来说，同样的项目C#也要比Java周期短，程序员开发轻松很多，难道这个世道对Java程序员这么不公平吗？没有理由下的功夫少，却得

到同样的收获，所谓世上没有白吃的午餐。?

经过我对C#和.Net的粗浅研究，我发现其实这是一个傻瓜相机和专业相机的问题。MS做出来的.Net的好学，易用，就如同傻瓜相机一样，一按就OK，不过照片质量一般。

专业相机麻烦是麻烦，不过经过专业人士的手，拍出来的都是高质量的照片，当然你让普通非专业人员去操纵专业相机确实太勉强了一些。?

.Net傻瓜相机确实太方便了，方便到了对组件的管理都对程序员透明化了。数据库缓冲池是由OLE?DB?Driver自动管理的；组件的管理是由MTS自动管理的，程序员不需要

去管这些中间层的问题，开发好组件，用GAC注册一下就好了，使用的过程中，由.Net平台的MTS等等实际上完成App?Server功能的服务自动处理。.Net?Framkwork?

Configuration配置工具也是如此的简单，都是MS在帮你代劳。在运行.Net程序的平台上注意一下dllhost.dll这个进程，就是专门管理组件的。?

不过从反面的角度来看，开发人员丧失了对组件部署的控制能力。在J2EE的世界，EJB或者说J2EE部署者是一个很重要的脚色，绝对不是可有可无，企业应用软件的运行

性能很大程度上依赖对对于中间层组件的部署和性能调节和排错。所以EJB组件本身就是一个可以通过内部的XML配置文件参数进行性能自调节的组件，App?Server更是提

供了数量庞大，功能繁多的调节和部署选择。对于一个要求比较严格的企业软件来说，你要提供高效，稳定和安全的运行，手工进行复杂的tunning是必须的。对于只有

一个全自动按钮的.Net傻瓜相机来说，实在是无能为力。?

所以有所得就必有所失，.Net傻瓜相机在赢得了大部分普通程序员的同时，仍然无法进入企业高端领域，或者至少在目前是如此。不过不排除将来有这个可能性。?

再看J2EE，EJB确实笨拙，开发起来速度也慢，但是一个构造良好，设计合理的J2EE应用经过高手的tunning，绝对是稳如磐石，令人放心。其系统的质量也不是目前的.Net

所能比的。?

说到这里觉得很有趣，MS从开始到现在，几乎所有的软件产品都在充当傻瓜相机的角色，就是到了.Net，MS也没能改变宿命。?

Windows?vs?Unix?
SQL?Server?vs?Oracle?
.Net?vs?J2EE?

所以我敢断定，将来J2EE和.Net的处境也会类似今天服务器市场的Windows?Server与Unix，数据库市场的SQL?Server和Oracle。普通应用会更多的采用.Net，而高端应用更多

采用J2EE。另外.Net还有一个不利的因素是J2EE虽然好像阳春白雪，其实下里巴人。J2EE既可以采用昂贵的商业App?Server和DB的强强组合，也可以采用完全不要钱的免费

方案，用成本来冲击低端市场，所谓各有各的活法。这也是MS比较头疼的。?
 
  

4、分布式领域的不成熟

这体现在几个方面：

(1)分布式应用的Session管理

.Net的方案是几台AppServer把全局Session放在一个共享的SQLServer中，实在是...笨拙，不用再评价了！
好好学习一下Weblogic集群的内存复制技术吧！.Net还差的远呢

(2).Net的分布式组件

MS的DCOM已经过时了，让我们看看在.Net里面如何实现分布式组件。
首先在.Net中，普通组件和分布式组件是不同的，在编写代码的时候采用的方法就不同。一般组件类似于J2EE中的普通类，分布式组件要采用TCPChannel或者HTTPChannel

来实现，完全两种不同的编程模型，MS建议采用HTTPChannel，因为可以穿越防火墙。而对于J2EE应用来说，一般商业组件都采用EJB编写，分布还是不分布，区别只是部

署的时候放不放在一台机器而已。我没有仔细研究过TCPChaneel或者HTTPChannel，不便于和EJB做对比，不过感觉上，这种Channel的可编程性和可管理性比EJB还差得远

。

(3)XMLWebServices

.Net上的WebServices加了一个耐人寻味的XML，什么原因大家体会一下。.Net的WebServices实现要靠IIS的ASP.Net，把组件以asmx的后缀放到IIS的Web目录下，当通过浏览器

第一次访问的时候，WebServices自动编译和发布，同时生成WSDL。编程起来倒是好方便，但是我隐隐约约的感觉到MS的WebServices方案另有用意。什么用意呢？联想到

第(2)点，我觉得MS的XMLWebServices是DCOM的替代品。也就是说MS没有想到一个更好的解决分布式组件的方法，既可以容易的使用C#编程，同时又很容易部署，很容易

进行分布式组件调用。万般无奈之下，在上面的Channel方案之外，又搞出这个XMLWebServices，其实就是MS的分布式组件而已。但是HTTPSOAP调用的效率和安全性目前

还比较差，还不能和EJB调用相比。况且XMLWebServices仍然没有解决可管理性的问题，WebServices的性能调节看来只能靠IIS了。看看吧，EJB确实够笨拙，但是可编程能

力，可管理能力，至今仍然是MS望尘莫及的。

所以就目前的.Net框架来说，MS还是暴露了在企业领域资历不够的弱点，Anders是程序语言设计的天才，设计了TurbolPascal(也是我最早最喜欢的编程语言，在高一开始学

习)，Delphi和C#，不过他还不是企业领域的天才。

不排除.Net将来有赶上来的可能，不过目前J2EE在分布式领域还有很大领先优势，只不过Sun不太挣气了。

5、看似不错的WebForm

WebForm也是我觉得很新颖的技术，甚至觉得很有前途，不过实际试用之后，我出了一口气，“不过如此”

Web页面由于HTML的限制，表现能力很弱，于是WebForm技术出来了，就像GUI程序设计一样来拖拉控件来设计Web页面，好像很不错，其实问题也有不少。因为Web页面

的设计和Web页面的编程是分离的，美工人员使用DW设计Web页面，程序人员嵌入代码。程序人员不负责Web页面的设计，如果都象WebForm这样，使用服务端动态生成

HTML的表单元素的话，那么美工人员用DW一打开Web页面源代码，就会发现和在Visual.NetStudio里面的Web页面已经面目全非了。除非Web程序员把美工的活一肩挑，否

则WebForm在Web程序员和美工之间的配合就是一个大问题。

6、C#的程序集还不够丰富

C#出来的时间比较短，而且因为出自MS之手，所以难以吸引大批的Opensource人员，目前Java的Opensource的类库极大的丰富，几乎所有你能够想得到的功能，一定可以

在网络上找到某些人已经编写好的Java类库提供你来使用，这种优势也是很可怕的。C#目前达不到，以后也达不到这样的境界。

我对.Net的认识还很不够，J2EEvs.Net是一个热门话题，众说纷纭。在我粗浅的研究了C#和.Net之后初步的认为，从技术角度来看，如果你对J2EE已经非常精通了，那么目

前也确实没有必要转到.Net上，除非出于市场的需要，或者其它的什么商业因素。况且在企业应用领域，.Net还做得不够好，仍然有很长的路要走。未来将是.Net和J2EE共

存的局面，就像WindowsvsUnix一样，低端应用更多的采用.Net，高端应用更多的采用J2EE。

 

我觉得C#从语言角度来说，设计的不够严谨。不单是语言，整个.net体系结构都能给我这种感觉，很多方面都是为了开发时候的方便和快捷，屏蔽了或者隐藏了很多比较

复杂的实现，而这些东西在Java中，都是程序员必须自己手工去处理的。

举个简单的例子，对于Java的RMI来说，要编写interface和interface的实现类，这个实现类要可以序列化，并且要用工具生成stub和skelton类。远程调用的客户端只需要一个

interace类就可以了。

在.net里面，只需要写一个实现类，象interface类，stub，skelton全部都是.net自动生成的，程序员看不到也不知道其内部运作的情况。这样情况下，客户端就必须有一份服

务端实现类的拷贝，而从底层来说，实际上，客户端需要的是实现类的接口，而不是实现类本身。

更进一步，如果使用IIS作为远程服务端提供者，所有的远程处理都写在配置文件里面，编写一个本地对象和编写一个远程对象是完全一样的。

所以我觉得.net像傻瓜相机，程序员的工作已经被极大的简化了，更何况还有一个高度智能化的IDE来帮助你生成代码。生产效率的提高真不是一倍两倍，而是五六倍。

Java的体系特别的严谨，所有的架构都是一丝不苟，与理论高度吻合，缺点是未免不够灵活，实现起来比较烦琐，工作量比较大。不过一个设计优秀的Java软件是经得起

千锤百炼的，非常稳固。

.net体系设计的更加灵活，极大的提高了生产率。同时也极大得降低了服务端中间层开发的门槛，所以估计未来的服务端程序员将大幅度的贬值，而这就是.net普及的后

果。

另外我在使用的过程中发现.net运行事务处理，对象池，分布式应用这些比较高端的东西的时候，消耗的CPU和内存资源也是惊人的高，
AppServer(IIS,ASP.Net,COM+)+SQLServer2000这样的组合跑类似的应用消耗的CPU和内存资源已经超过了
AppServer(WeblogicServer7.0)+Oracle8.1.7这样的组合。

而效率并没有明显比JavaBased高，甚至感觉.net处理事务，对象池相当的缓慢。
——————————————————————————————————————————

 
 
   
一、关于跨平台问题。

这点我未深入研空，只谈谈我的感觉，我感觉Java/C#的跨平台实际上是个比较巧妙的骗局。因为它们的跨平台性还是要某个厂家或厂家联盟的支持，这种平台不过是通

过在不同的“硬平台”基础之上设置一个接口统一的“软平台”，这梓表面上是跨越了“硬平台”，实际“软平台”的限制仍是无法跨越的；或若厂家未生产某一“硬平台”的“软平

台”那这个“硬平台”你还上跨不上去的。真正的跨平台技术是互联上的“htm/xml”,这是目前任何厂家无法据为己有而又不得不遵守的标准。

二、关于指针问题。

C#/Java 借鉴了C++，但去掉了C++的双刃剑――指针（当然不是完全去掉，在某种形式下还是可以用的，或者在使用时受到了比较大的限制）。于是关于C#/Java、C++的优

劣问题往往围绕着指针展开，“用C#/Java，还是用C++”对于许多C/C++程序员来说，就象哈姆雷特的“是生存，还是死亡”让人踌躇徘徊。其实指针的使用与否，其本质就是

内存的分配、访问与释放权由谁掌握的问题。

使用指针，由程序员根据需要分配、访问内存，程序运行时动作明确直接没有额外的处理步骤，程序的执行效率就高，但若程序员忘了释放内存或释放内存的策略不够

周全，就会产生不可预知的问题，而且这种问题往往是比较严重。

不使用指针，并不意味着内存的分配、访问与释放不须处理，只不过是这些工作由编译器生成的通用“内存管理器”完成了，因此程序执行时，必须增加额外的内存管理

动作，所以执行效率相对上种方式而言有所下降。由于“内存管理器”的运作是基于业内专业人士制定的比较完善内存管理机制，因而安全程度较高。但实际上，由于内

存的分配、访问、使用、释放的情况比较复杂，这种安全性并不是100%的。也就是说安全的保证是由“另外的人”负责的，这种情况下，一旦出现问题，你无法查清问题

所在，或即使你查清问题所在，也无法纠正。

好了，关于指针，一边是100%的效率、60%的安全性、100%的自由，一边是60%的效率、99%的安全性、100%枷锁，你选择吧。我想对于“高手”而言，自信也罢、固执也罢，

选择指针是他们骨子里自由与冒险精神的决定。

“是生，是死――这是一个值得考虑的问题。”――但不要丧失了行动的能力。