NET and C#翻译.docVIP

外文资料翻译译文 .NET与C# .net既是运行库又是开发平台，因为.net负责C#程序的运行时编译（JIT，Just In Time）和代码安全性管理，同时它又为C#和其他.net语言（,c++.net等）提供代码支持，C#语言是一种面向对象的程序设计语言，可是它本身连一个类都不包括，所有的类都包含在.net中，这也是为什么.net下一种语言编写的类可以被另一种语言调用的原因因为它们都是同一个基类（Object类）的派生类。 另外，微软的目标是让.net彻底改变软件的开发、发行和使用方式，微软的.net架构中包含了两方面的组件：“.net通用运行库”和“.net类库”，从这里就可以看出.net与C#的关系。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调用，显得高明。 在Windows平台上.Net CLR比Java的JRE速度快，联想到当年MS做的JVM，所以也不是很奇怪。只不过CLR速度足够快的话，C#字节码运行起来，普通应用就不会感觉出来速度比纯本地代码慢。我的感觉就是这样，基本上感觉不出来CLR启动和加载程序集的明显延迟，而不管用AWT，Swing还是SWT，JVM启动和加载类库的延迟是非常明显的，这就是真正不妙的地方了，不管Sun，IBM，BEA还是Open Souce 社区，在JVM的效率上还要继续加油。开发工具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部署本身的高