c#争议

一，语言特性(相对于C和C++，这个语言在许多方面进行了限制和增强)

继承C++的底层高效的特性，保留了对底层操作系统API的直接调用和指针，保留并增强了枚举。虽然还达不到纯种C那样快到可以写系统软件，但也避免了Java的速度问题以及JNI的笨拙调用C++。

指针只能被用于不安全模式。大多数对象访问通过安全的引用实现，以避免无效的调用，并且有许多算法用于验证溢出，指针只能用于调用值类型，以及受垃圾回收器控制的托管对象。

枚举位于其所在的名字空间中。

避免了C++的内存管理与指针问题，指针被限制使用，支持垃圾回收(无用内存回收),内存自动管理。

对象不能被显式释放，代替为当不存在被引用时通过垃圾回收器回收。

只允许单重继承，但是一个类可以实现多个接口。

类型安全：在CS中不能进行不安全的类型转换象将double转换成boolean.值类型(常量类型)被初始化为零值而引用类型(对象和类被编译器自动初始化为零值.数组类型下标从零开始而且进行越界检查.类型溢出将被检查.整形数值0和1不再作为布尔值出现.CS中的布尔值是纯粹的true和false值。而且没有更多的”=“操作符和”==“操作符错误.”==“被用于进行比较操作而”=“被用做赋值操作. C#比C++更加类型安全。默认的安全转换是隐式转换，例如加宽整型和从派生类转换为基类。而布尔型同整型，及枚举型同整型不允许隐式转换，非空指针（通过引用相似对象）同用户定义类型的隐式转换必段被显式的确定，不同于C++的复制构造函数。

数组声明语法不同（”int[] a = new int[5]” 而不是 “int a[5]“）。

C#中没有模版，但是在C# 2.0中引入了泛型，并且支持一些C++模版不支持的特性。比如泛型参数中的类型约束。另一方面，表达式不能像C++模版中被用于类型参数。

属性支持，使用类似访问成员的方式调用。

完整的反射支持。

二，优点

1，CS/.Net框架学习比Java/J2EE轻松太多了。从开发角度来说，同样的项目CS也要比Java周期短，程序员开发轻松很多。开发工具IDE对于GUI开发和企业应用意义非凡，Visual .Net Studio比起JBuilder/Eclipse强大得太多。

Java，Eclipse空有一个SWT，却没有一个好点的GUI开发环境。JBuilder在AWT，Swing和SWT图形库的布局设计上欠缺。当然这也是受到JAVA的跨平台要求的先天限制不能用像素定位。而VS只在Windows平台上实现，直接就采用像素定位达到“所见即所得”了。其中CS在GUI开发方面比VB/VC(MFC)还更加优秀，可与Borland的C++ Builder比美。

CS的整个开发过程一体化(SQL Server/IIS/MTS/IE)，而JBuilder需要考虑DB，App Server各种不同的软件实现，在图形设计器里面设计EJB，从DB里面导入Entity Bean，方便的在所有的主流的App Server上自动编译/部署/测试EJB，也算做到极致了。但由于App Server五花八门和EJB部署本身的高度复杂度的原因，Java的企业开发也是远远不如CS来的快捷和方便。

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

2，相互兼容性：CLR支持不止一种语言,诸如 CS,VB.NET,Jscript,ASP.NET,C++.Delphi. CS提供对COM和基于windows的应用程序的原始的支持.允许对原始指针的有限制的使用.用户不再需要显式的实现unkown和其它COM界面,这些功能已经内建.CS允许用户将指针作为不安全的代码段来操作老的代码.VB.NET和其它中间代码语言中的组件可以在CS中直接使用. CS可以将任何组件转变为WEB服务而跨平台使用，作为后来者的CS对HTML，XML，SOAP（简单对象存取协议）等WEB新标准结合得较好，方便了应用的扩展。

3，可伸缩性和可升级性：.NET引入了零部件的概念,它们通过其”手册”具有自描述的功能.手册确立了零部件的身份,版本,语言和数字签名等.零部件不需要在任何地方注册.要扩展我们的程序,我们只需要删除老的文件并用新的文件来升级它们.不需要注册动态链接库.升级软件组件的过程只是一个错误探测的任务.对代码的修改能够影响现存的程序,CS在语言中支持版本修改.对界面和方法重载的支持使得复杂的程序框架能随着时间发展和进化.

4，在Windows平台上.Net CLR比Java的JRE速度快，联想到当年MS做的JVM，所以也不是很奇怪。只不过CLR速度足够快的话，CS字节码运行起来，普通应用就不会感觉出来速度比纯本地代码慢。我的感觉就是这样，基本上感觉不出来CLR启动和加载程序集的明显延迟，而不管用AWT，Swing还是SWT，JVM启动和加载类库的延迟是非常明显的，这就是真正不妙的地方了，不管Sun，IBM，BEA还是Open Souce 社区，在JVM的效率上还要继续加油。

5.面向对象：CS支持数据封装,继承,多态和对象界面(即java中的interface关键字).(int,float,double)在java中都不是对象,但是CS引入和结构体(structs)来使原始数据类型变成对象int i=1;String a=i Tostring();转换(或者)Boxing 6，C#程序的变量命名方式，不再鼓励使用老式的匈牙利记法，而推荐使用Pascal记法，这也使得这种语言看上去更加现代。或许在一个一切都是Object的语言里，为变量加上表示类型的前缀，意义的确不大:) 三，弱点 1、.Net平台支持多语言从技术上和开发角度来说是噱头，这完全是一个商业阴谋。从ISV角度来看，完全没有支持多语言的必要，甚至反而是维护升级的灾难。支持多语言的唯一目的在于吸引其它语言的开发人员转到.Net平台上来，但你会发现用CS比较好，也许就会转到CS。 2、.Net在将来也不可能支持其它操作系统平台。 CS将把微软领向何方就一目了然了。因为所有项目编写会只依靠MSIL和CLS JIT编译程序。这样CS或任何MSIL前端语言比Java任何时候都快。但很不幸，程序设计和编译程序级的优化不能在非微软的平台上充分利用，想在非 Windows平台上展开.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开放CS语言和CLI的规范又是一个商业阴谋，表面上装出一副拥抱开放的姿态，骨子里面却垄断的很。而且从MS的商业行为也可以看出这一点，我们知道MS把全部身家都压在.Net上和J2EE阵营竞争，如果.Net是一个开放平台，可以自由移植到Linux上，那么MS有什么理由不支持Linux 操作系统呢？如果Linux上的.Net 支持的很好并且普及开来的话，J2EE恐怕只有在AIX和Solaris上苟延残喘的份了。正是因为MS要把.Net锁定Windows，所以才害怕 Linux，如果Linux在服务器市场击败了Windows，那么.Net也只剩下苟延残喘的份了。所以现在MS视Linux为眼中钉，肉中刺。 所以MS开放CS和CLI，除了做作姿态之外，也可以在更多的OS上普及CS编程的教学，等你们熟悉了CS编程，再乖乖的在我的Windows上替我开发吧。 3、傻瓜式开发，难以进入企业高端领域 组件的自动化管理固然方便，但反过来也让开发人员丧失了对组件部署的控制能力。在J2EE的世界，EJB或者说J2EE部署者是一个很重要的脚色，绝对不是可有可无，企业应用软件的运行性能很大程度上依赖对对于中间层组件的部署和性能调节和排错。所以EJB组件本身就是一个可以通过内部的XML配置文件参数进行性能自调节的组件，App Server更是提供了数量庞大，功能繁多的调节和部署选择。对于一个要求比较严格的企业软件来说，你要提供高效，稳定和安全的运行，手工进行复杂的 tunning是必须的。对于只有一个全自动按钮的.Net傻瓜相机来说，实在是无能为力。 2EE，EJB确实笨拙，开发起来速度也慢，但是一个构造良好，设计合理的J2EE应用经过高手的tunning，绝对是稳如磐石，令人放心。其系统的质量也不是目前的.Net所能比的。 另外.Net还有一个不利的因素是J2EE虽然好像阳春白雪，其实下里巴人。J2EE既可以采用昂贵的商业App Server和DB的强强组合，也可以采用完全不要钱的免费方案，用成本来冲击低端市场，所谓各有各的活法。这也是MS比较头疼的。 所以，普通应用会更多的采用.Net/Windows Server/SQL Server。而高端应用更多采用J2EE/Unix/Oracle。 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没有想到一个更好的解决分布式组件的方法，既可以容易的使用CS编程，同时又很容易部署，很容易进行分布式组件调用。万般无奈之下，在上面的Channel方案之外，又搞出这个XML Web Services，其实就是MS的分布式组件而已。但是HTTP SOAP调用的效率和安全性目前还比较差，还不能和EJB调用相比。况且XML Web Services仍然没有解决可管理性的问题，Web Services的性能调节看来只能靠IIS了。看看吧，EJB确实够笨拙，但是可编程能力，可管理能力，至今仍然是MS望尘莫及的。 所以就目前的.Net框架来说，MS还是暴露了在企业领域资历不够的弱点，Anders是程序语言设计的天才，设计了Turbol Pascal(也是我最早最喜欢的编程语言，在高一开始学习)，Delphi和CS，不过他还不是企业领域的天才。 不排除.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、CS的程序集还不够丰富 CS出来的时间比较短，而且因为出自MS之手，所以难以吸引大批的Opensource人员，目前Java的Opensource的类库极大的丰富，几乎所有你能够想得到的功能，一定可以在网络上找到某些人已经编写好的Java类库提供你来使用，这种优势也是很可怕的。CS目前达不到，以后也达不到这样的境界。 我对.Net的认识还很不够，J2EE vs .Net是一个热门话题，众说纷纭。在我粗浅的研究了CS和.Net之后初步的认为，从技术角度来看，如果你对J2EE已经非常精通了，那么目前也确实没有必要转到.Net上，除非出于市场的需要，或者其它的什么商业因素。况且在企业应用领域，.Net还做得不够好，仍然有很长的路要走。未来将是.Net 和J2EE共存的局面，就像Windows vs Unix一样，低端应用更多的采用.Net，高端应用更多的采用J2EE。 我觉得CS从语言角度来说，设计的不够严谨。不单是语言，整个.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处理事务，对象池相当的缓慢。