研究了一下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的方案是几台App Server把全局Session放在一个共享的SQL Server中，实在是...笨拙，不用再评价了！
好好学习一下Weblogic集群的内存复制技术吧！.Net还差的远呢
(2) .Net的分布式组件
MS的DCOM已经过时了，让我们看看在.Net里面如何实现分布式组件。
首先在.Net中，普通组件和分布式组件是不同的，在编写代码的时候采用的方法就不同。一般组件类似于J2EE中的普通类，分布式组件要采用TCP Channel或者HTTP Channel来实现，完全两种不同的编程模型，MS建议采用HTTP Channel，因为可以穿越防火墙。而对于J2EE应用来说，一般商业组件都采用EJB编写，分布还是不分布，区别只是部署的时候放不放在一台机器而已。我没有仔细研究过TCP Chaneel或者HTTP Channel，不便于和EJB做对比，不过感觉上，这种Channel的可编程性和可管理性比EJB还差得远。
(3) XML Web Services
.Net 上的Web Services加了一个耐人寻味的XML，什么原因大家体会一下。.Net的Web Services实现要靠IIS的ASP.Net，把组件以asmx的后缀放到IIS的Web目录下，当通过浏览器第一次访问的时候，Web Services自动编译和发布，同时生成WSDL。编程起来倒是好方便，但是我隐隐约约的感觉到MS的Web Services方案另有用意。什么用意呢？联想到第(2)点，我觉得MS的XML Web Services是DCOM的替代品。也就是说MS没有想到一个更好的解决分布式组件的方法，既可以容易的使用C#编程，同时又很容易部署，很容易进行分布式组件调用。万般无奈之下，在上面的Channel方案之外，又搞出这个XML Web Services，其实就是MS的分布式组件而已。但是HTTP SOAP调用的效率和安全性目前还比较差，还不能和EJB调用相比。况且XML Web Services仍然没有解决可管理性的问题，Web Services的性能调节看来只能靠IIS了。看看吧，EJB确实够笨拙，但是可编程能力，可管理能力，至今仍然是MS望尘莫及的。
所以就目前的.Net框架来说，MS还是暴露了在企业领域资历不够的弱点，Anders是程序语言设计的天才，设计了Turbol Pascal(也是我最早最喜欢的编程语言，在高一开始学习)，Delphi和C#，不过他还不是企业领域的天才。
不排除.Net将来有赶上来的可能，不过目前J2EE在分布式领域还有很大领先优势，只不过Sun不太挣气了。
5、看似不错的Web Form
Web Form也是我觉得很新颖的技术，甚至觉得很有前途，不过实际试用之后，我出了一口气，“不过如此”
Web页面由于HTML的限制，表现能力很弱，于是Web Form技术出来了，就像GUI程序设计一样来拖拉控件来设计Web页面，好像很不错，其实问题也有不少。因为Web页面的设计和Web页面的编程是分离的，美工人员使用DW设计Web页面，程序人员嵌入代码。程序人员不负责Web页面的设计，如果都象Web Form这样，使用服务端动态生成HTML的表单元素的话，那么美工人员用DW一打开Web页面源代码，就会发现和在Visual .Net Studio里面的Web页面已经面目全非了。除非Web程序员把美工的活一肩挑，否则Web Form在Web程序员和美工之间的配合就是一个大问题。
6、C#的程序集还不够丰富
C#出来的时间比较短，而且因为出自MS之手，所以难以吸引大批的Opensource人员，目前Java的Opensource的类库极大的丰富，几乎所有你能够想得到的功能，一定可以在网络上找到某些人已经编写好的Java类库提供你来使用，这种优势也是很可怕的。C#目前达不到，以后也达不到这样的境界。
我对.Net的认识还很不够，J2EE vs .Net是一个热门话题，众说纷纭。在我粗浅的研究了C#和.Net之后初步的认为，从技术角度来看，如果你对J2EE已经非常精通了，那么目前也确实没有必要转到.Net上，除非出于市场的需要，或者其它的什么商业因素。况且在企业应用领域，.Net还做得不够好，仍然有很长的路要走。未来将是.Net和J2EE共存的局面，就像Windows vs Unix一样，低端应用更多的采用.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和内存资源也是惊人的高，
App Server(IIS, ASP.Net, COM+) + SQL Server 2000这样的组合跑类似的应用消耗的CPU和内存资源已经超过了
App Server(Weblogic Server7.0) + Oracle8.1.7 这样的组合。
而效率并没有明显比Java Based高，甚至感觉.net处理事务，对象池相当的缓慢。
