第二章 .NET和C#评说

一，概论
　　Windows内建了COM基础设施(最成功的跨语言非跨平台机制)而导致了基于COM的ASP的巨大成功。未来的Windows.NET操作系统也许就将把C#.net和VB.net推上新的王者之位。
　　Web Services技术并非微软独创，也不是由.NET带来的。
　　.NET框架由通用语言运行时（Common Language Runtime，CLR）和.NET框架类库构成。.NET在操作系统之上又加了一层抽象，.NET本身并不是操作系统。
　 　.NET和Java的竞争将长期存在。从微软pre.NET技术过渡到.NET的创新过程中，肯定会淘汰掉一些抱残守缺的开发人员。但ASP和 ASP.NET几乎完全不同。普通ASP开发人员过渡到ASP.NET的痛苦，也许不会少于比起从Visual Basic过渡到Visual Basic .NET。
　　.NET的最终目的就是让用户在任何地方、任何时间，以及利用任何设备都能访问他们所需要的信息、文件和程序。
　　.NET包括4个重要特点，一是软件变服务，二是基于XML的共同语言，三是融合多种设备和平台，四是新一代的人机界面。这四个特点基本上覆盖了.NET的技术特征。
　　.NET Framework是开发应用程序的一个新平台。包括通用语言运行环境、Framework类库和Active Server Pages+


　　CS从C和C++演变而来，本质上是.NET CLR语义的C风格的语法表达。是MS为.net平台而开发的一种新型编程语言:牺牲C++一点底层功能，以获得更方便和更产品化。C#无疑是.NET水 中最引人注目的鱼。在某种程度上可以把CS与当年MS的明星ASP相提并论。我们能够用CS开发控制台应用程序,Windows应用程序,Web应用程 序.CS会吸引理智面向MS平台的公司与个人，尤其是朝气勃勃的新人。

二，C#优点
　　1，继承C++的底层高效的特性，保留了对底层操作系统API的直接调用和指针，保留并增强了枚举。虽然还达不到纯种C那样快到可以写系统软件，但也避免了Java的速度问题以及JNI的笨拙调用C++。
　 　2，继承Visual Basic高产特性。CS就象一个易学易用的傻瓜自动相机。数据库缓冲是由OLE DB Driver自动管理；组件由MTS自动管理(dllhost.dll进程)，.Net Framkwork Configuration配置工具也简单至极。对于大部分普通程序员，她具有极大诱惑。
　　3，避免了C++的内存管理与指针问题，指针被限制使用，支持垃圾回收(无用内存回收),内存自动管理。
　　4，CS/.Net框架学习比Java/J2EE轻松太多了。
　　5.CLR支持不止一种语言,诸如 CS,VB.NET,Jscript,ASP.NET,C++.Delphi..
　 　6，类型安全：在CS中不能进行不安全的类型转换象将double转换成boolean.值类型(常量类型)被初始化为零值而引用类型(对象和类被编译 器自动初始化为零值.数组类型下标从零开始而且进行越界检查.类型溢出将被检查.整形数值0和1不再作为布尔值出现.CS中的布尔值是纯粹的true和 false值。而且没有更多的"="操作符和"=="操作符错误."=="被用于进行比较操作而"="被用做赋值操作.
　　7.相互兼容性：CS 提供对COM和基于windows的应用程序的原始的支持.允许对原始指针的有限制的使用.用户不再需要显式的实现unkown和其它COM界面,这些功 能已经内建.CS允许用户将指针作为不安全的代码段来操作老的代码.VB.NET和其它中间代码语言中的组件可以在CS中直接使用.
　　8. 可伸缩性和可升级性：.NET引入了零部件的概念,它们通过其"手册"具有自描述的功能.手册确立了零部件的身份,版本,语言和数字签名等.零部件不需要 在任何地方注册.要扩展我们的程序,我们只需要删除老的文件并用新的文件来升级它们.不需要注册动态链接库.升级软件组件的过程只是一个错误探测的任务. 对代码的修改能够影响现存的程序,CS在语言中支持版本修改.对界面和方法重载的支持使得复杂的程序框架能随着时间发展和进化.
　　9，在 Windows平台上.Net CLR比Java的JRE速度快，联想到当年MS做的JVM，所以也不是很奇怪。只不过CLR速度足够快的话，CS字节码运行起来，普通应用就不会感觉出 来速度比纯本地代码慢。我的感觉就是这样，基本上感觉不出来CLR启动和加载程序集的明显延迟，而不管用AWT，Swing还是SWT，JVM启动和加载 类库的延迟是非常明显的，这就是真正不妙的地方了，不管Sun，IBM，BEA还是Open Souce 社区，在JVM的效率上还要继续加油。
　　10，从开发角度来说，同样的项目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开发周期长两三倍的现象。
　　11，与WEB开发相结合：CS可以将任何组件转变为WEB服务而跨平台使用，作为后来者的CS对HTML，XML，SOAP（简单对象存取协议）等WEB新标准结合得较好，方便了应用的扩展。
　 　12，面向对象：CS支持数据封装,继承,多态和对象界面(即java中的interface关键字).(int,float,double)在 java中都不是对象,但是CS引入和结构体(structs)来使原始数据类型变成对象int i=1;String a=i Tostring();//转换(或者)Boxing
　　13，C#程序的变量命名方式，不再鼓励使用老式的匈牙利记法，而推荐使用Pascal记法，这也使得这种语言看上去更加现代。或许在一个一切都是Object的语言里，为变量加上表示类型的前缀，意义的确不大:)

三，CS的弱点

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处理事务，对象池相当的缓慢。

C#速成
http://bbs.dvbbs.net/dispbbs.asp?BoardID=3&ID=452695&replyID=&skin=1

C#和.Net的初步研究 2004-2-10 兖矿集团
C#断想 荣耀 2002秋