为什么要学习.NET

 为什么微软设计和发布 .NET? 相信大多数人都会认为微软推出 .NET 是为了与 JAVA 正面竞争，不可否认这是原因之一，但是如果你回顾 Windows 下微软技术的发展历史，你就会发现，几经岁月的微软技术已经显得越来越壅肿 , 无论在易用性、开发效率和安全性上都积累了诸多诟病，很多技术都是在需求的驱动下诞生的，都缺乏整体规划，微软迫切地需要对其所有的技术进行一次重构，现在就让我们一起回顾一下微软技术的发展历史，来认识 .NET 技术诞生的必要性：

　　在 .NET 之前， Windows 平台下的编程技术主要是 Win32 SDK, ASP,COM, DCOM, ADO 等技术，这些技术在后来也有了一个统一的名字叫 Windows DNA ，和 .NET 是一系列技术的集合一样， Windows DNA 是这些一系列技术的统称，为了加快软件开发，微软为 C++ 程序员提供了 VC/MFC 开发工具，为 Basic 程序员 提供了 VB 等，由于语言本身存在的先天差异 ( 例如数据类型不相同，内存管理也不同等等 ) ，微软没有办法做到 VB 和 VC 程序引用同一套类库，所以微软为每一种语言都提供其单独的 Runtime 类库、单独的数据库类，不同的 GUI 构建方式等。由于类库的大部分功能都基本相同，因此，为不同的语言设计和维护不同的类库是一件很没有效率的事情。（后注： .NET 是所有 的 .NET 语言都引用同一套 .NET Framework ）

　　值得一提的是， Borland 公司的 C++ Builder 与 Delphi 共同使用的是同一套类库，这个类库就是 VCL ，为什么 Borland 做到两个不同的语言引用同一套类库呢？ 因为 Borland 拥有 Pascal, Borland 通过修改编译器来修改 Pascal 语言使得它在数据类型和内存管理方面与 C++ 相拟，使得用这两种语言编译出来的程序能二进制兼容。虽然微软拥有 Basic, 但是 Basic 的先天优势是易学易用，微软无意去修改 Basic 使得 Basic 变得复杂。

　　微软使用 COM 来解决语言间的组件重用问题，并提出组件编程模型的概念， COM 的基本原理是通过定义一些编程契约，使得按照这些契约编写出来的组件 ( 以 dll/exe 的形式存在 ) 可以跨语言和跨平台地进行重用。

　 　在 COM 推出之前，微软和 Borland 在开发工具的战场上斗得你死我活，而微软凭靠着 OLE 技术赢得了重要的一役胜利，微软在 OLE 的基础上创造了 COM 技术，并大幅地使用 COM 技术来构建 Windows 下的软件组件，其中， ADO 就是一个常用 COM 组件，不同的编程语言都可以调用 ADO 来访问和操 作数据库，因此， ASP 程序员会惊呀地发现，他用 ADO 编写的访问数据库的代码看起来与 VC 程序员访问数据库的代码是如此的相拟。

　　通过对微软技术历史的分析，可以发现 COM 的产生是一个偶然，当时微软为了对搞 Apple 的文件技术，从而推出 OLE(Object Linking and Embedding ，对象连接与嵌入 ) ， OLE 的目的是让文件可以即时编辑，例如 Word 文档可以嵌到 Excel 中编辑， Excel 表格也可以嵌到 Word 中编辑， OLE 的成功使得微软察觉到跨语言组件重用的重要性，于是微软从 OLE 中抽取出一些重要的特性，并实现了 COM ，然后再用 COM 重写了 OLE 组件，所以可以说， COM 是在缺乏整体规划的情况下设计出来的，加上 OLE 庞大和复杂（当年 Borland 与微软的开发工具大战， Borland 在 OLE 上面吃了大亏），再加上随着需求的不断增加和修补， COM 并不易用，但这并不防止 COM 组件的成功，在 .NET 之前， COM 已经成为 Windows 下重要的组件编程技术，很多重要的组件 ( 如 ADO, ActiveX 组件 ) 等都是基于 COM 技术开发的，当时业界较流行的做法是 VC 程序员编写 COM 组件，然后由 VB 程序员或 ASP 程序员来将 COM 组件组装成提供给最终用户的软件产品， .NET 之前， COM 就是这样很好地解决了多种语言之间的组件重用问题。

　　以 Win32 SDK, COM 技术基础组成的 Windows DNA 技术经历了整个 90 年代的发展，期间根据市场需求不断的修修补补，已经非常壅肿，且积累了诸多诟病，某些技术过于复杂，开发效率低等，这些问题都成为了设计 .NET 的背景，下面我试图罗列出一些主要需要改进的地方 ( 列个大概，肯定不全，希望大家帮忙补充 ) ：

　　 1) COM 并不支持面向对象的诸多特性，例如不支持接口、继承等，在面向对象流行的今天已显得非常落后，目前大部分的生产力工具都是以面向对象为基础的（例如 UML 建模工具）。
　　 2) 编写 COM 组件对于新手来说比较复杂，必须要遵守一些较为繁琐的规则，安装和部署需要修改注册表，不便于测试和部署。
　 　 3) COM 组件基于 exe/dll 的形式存在，而 dll 是 Windows 下重要的组件存在形式，但是 dll 也成了 Windows 下软件不稳定的罪魁祸首，原因 是大部分主要的 dll 都存放在一个统一的目录： Windows/System32 ，当安装一个新软件或者升级软件到新版本时，新的 dll 会覆盖旧的 dll 文件，从而可能会导致现有的软件无法工作或者不稳定，这是大名鼎 鼎 的Dll Hell (Dll 地狱 ).
　　 4) COM 组件虽然可以跨语言进行调用，但是没有办法进行跨语言调试，例如在 VB 中调用 VC 编写的 COM 组件时，这个组件不能在 VB 中调试，造成软件调试困难。
　　 5) 安全性方面，软件没有办法知道自已所引用的组件是否已被非法修改，安全控制也只停留在用户级别的控制上，没有办法做到代码级别上的安全控制，例如没有办法做到限制某个组件只能读取文件内容，但不能将内容写入文件。

　　随着信息化的需求不断演进，以及 JAVA 的流行，以及云计算等一些概念的提出，微软迫切需要修改自身的技术来适合市场的需求，显然，微软有两种解决方案：

　　 1) 继续对 Windows DNA 的相关技术进行修修补补，在上面增加新功能，改进并修复错误。
　　 2) 重新规划一套新技术，解决现有技术存在的问题。

　 　微软选择了第 2 种方案，即重新规划一套新技术，在微软内部，新技术作为 COM 的更新版本被命名为 COM 2.0 （来源于 <<.NET 本质论 >> 一书），后来才改名为 CLR, 和 Windows DNA 以 COM 技术为基础一样， .NET 以 CLR为基础 ，而 CLR 显然可以看作是经过重构的、新版本的 COM ，只是新版本的 COM 比它的旧版本增强太大从而使 得它应该换个名字。微软用 .NET 这个名字来代替 Windows DNA ，来表示一系列新技术的统称 ( 其实就是一个商标 ) ，至于为什么使用 .NET 这个名字， NET 是网络的意思，微软使用 .NET 这个名字是预见未来将是网络应用、分布式计算的天下，而微软，已经做好了准备。

　　 .NET 设计的首要目标，就是要解决旧技术中的诸多问题，针对上面对旧技术需要改进的一些问题，我们再回头来看看 .NET 是如何改进这些问题的：

　 　 1) 引入中间语言技术，程序在编译后产出中间语言而不是机器码，在中间语言这一层直接支持面向对象技术，并定义常用数据类型，最大限度地缩短不同编程语言之间 的差异，使得不同编程语言编写的代码可以无缝集成起来，例如 VB 编写的类可以在 C# 中继承、创建实例等等，这在以前是无法想像的。

　　 2) 引用程序集的概念来解决 dll 地狱问题，安装新程序集不需要修改注册表，部署简单，不同的程序集版本可以同时存在，有趣的是，这个特性使得微软在推 出 .NET 新版本时，不用头痛去考虑旧 .NET 程序的兼容 (.NET 程序员也因为这个原因而对微软抱有不满 ) ，因为 .NET 的新旧类库可以相互共存，因此你的程序可以引用旧版本的 .NET 类库中的一部分，同时还可以引用新版 本 .NET 类库的另一部分，当然，这样的话，最终用户需要同时安装两个版本的 .NET Framework 。
　　 3) 引入 Click One 技术使软件的安装和更新更简便 。
　　 4) 支持代码级的安全控制。
　　 5) 中间语言技术使得跨平台成为可能，目前 MONE 项目已使得 .NET 程序可以运行在 Linux 下，甚至 iPhone 手机上。

 

总之， .NET 技术是微软技术一次全面的重构，所以要在 Windows 下进行程序开发，学习 .NET 是大势所趋，虽然旧的技术 (COM/MFC 等 ) 还将存活一段时间，但微软保留这些技术更多是为了兼容旧的程序， Windows 下要使用新的技术和新的功能，首选还是 .NET 。