我所认识的NetFramework

.NetFramework&C#第一部分：前言第二部分：.NetFramework第三部分：C#第四部分：总结前言：产生原因之一：技术原因1.1985～1991年：C搭配WindowsAPI。目前我们已很少用C和WindowsAPI写程序了，但还是有必要熟悉这样的技术，因为有些特殊的时候会用到。a)优点：灵活、运行速度快b)缺点：繁琐、语言单一（只能被C或理解C调用规范的语言使用）、面向过程开发效率低、维护困难2.1992～2001年：C++搭配MFC链接库(这段时间也是VisualBasic最风光的时候)。在历史上MFC是最多人用的Windows编程方法。a)优点：开发效率提高、灵活、执行效率高b)缺点：难学、语言单一、非完全面向对象3.1993～2002年：COM（ComponentObjectModel组件对象模型）是微软公司于1993年提出的一种组件技术，是软件对象组件之间相互通信的一种方式和规范，它是一种平台无关、语言中立、位置透明、支持网络的中间件技术。COM是OLE（ObjectLinkingandEmbedding对象链接和嵌入）的发展（而OLE又是DLL[DynamicLinkLibraries动态链接库]的发展），DCOM（DistributedCOM分布式COM，1996年）和COM+（DCOM+管理，1999年）则是COM的发展。ActiveX控件是COM的具体应用（如VBX和DirectX都是基于ActiveX的）。ATL（ActiveTemplateLibrary活动模板库）是开发COM的主要工具，也可以用MFC来直接开发COM，但是非常复杂。简单地说，COM是一种跨应用和语言共享二进制代码的方法。与C++不同，它提倡源代码重用。ATL便是一个很好的例证。源码级重用虽然好，但只能用于C++。它还带来了名字冲突的可能性，更不用说不断拷贝重用代码而导致工程膨胀和臃肿。Windows使用DLLs在二进制级共享代码。这也是Windows程序运行的关键——重用kernel32.dll,user32.dll等。但DLLs是针对C接口而写的，它们只能被C或理解C调用规范的语言使用。由编程语言来负责实现共享代码，而不是由DLLs本身。这样的话DLLs的使用受到限制。MFC引入了另外一种MFC扩展DLLs二进制共享机制。但它的使用仍受限制——只能在MFC程序中使用。COM通过定义二进制标准解决了这些问题，即COM明确指出二进制模块（DLLs和EXEs）必须被编译成与指定的结构匹配。这个标准也确切规定了在内存中如何组织COM对象。COM定义的二进制标准还必须独立于任何编程语言（如C++中的命名修饰）。一旦满足了这些条件，就可以轻松地从任何编程语言中存取这些模块。由编译器负责所产生的二进制代码与标准兼容。这样使后来的人就能更容易地使用这些二进制代码。在内存中，COM对象的这种标准形式在C++虚函数中偶尔用到，所以这就是为什么许多COM代码使用C++的原因。但是记住，编写模块所用的语言是无关的，因为结果二进制代码为所有语言可用。此外，COM不是Win32特有的。从理论上讲，它可以被移植到Unix或其它操作系统。但是我好像还从来没有在Windows以外的地方听说过COM。面向过程的编程重用函数、面向对象的编程重用类、范型编程重用的是算法的源代码，而组件编程则重用特定功能完整的程序模块。每个组件会提供一些标准且简单的应用接口，允许使用者设置和调整参数和属性。用户可以将不同来源的多个组件有机地结合在一起，快速构成一个符合实际需要（而且价格相对低廉）的复杂（大型）应用程序。组件区别于一般软件的主要特点，是其重用性（公用/通用）、可定制性（设置参数和属性）、自包容性（模块相对独立，功能相对完整）和互操作性（多个组件可协同工作）。可以简单方便地利用可视化工具来实现组件的集成，也是组件技术一个重要优点。普通的面向过程和面向对象的编程，一般会生成两种类型的软件——针对特定应用的可执行程序和面向通用编程的API库。前者包含你需要的各种特殊的具体功能，但必须从头到尾自己来创建，其中很多是低层次的重复劳动；后者虽然通用，但是却不能满足你的具体应用的特殊需要。组件技术提供了第三种途径，它将库的可重用性与特定程序的可定制性结合起来，让用户可以用可重用的组件来定制自己特定的应用程序。所以组件在某些方面类似于“可执行程序”，在另一些方面又类似于“库”。采用MFC编程，可选的项目类型为：MFC应用程序、MFCDLL和MFCActiveX控件，刚好对应于上面所讨论的可执行程序、库和组件这三类软件。使用组件来构造应用程序的工作（组件集成）非常简单，不需要专业程序员，普通用户就可以很快做到。但是设计和创建组件（组件编写）的工作却十分复杂，只有高水平的程序员才有可能完成。这也是为什么VB和Delphi会如此流行的真正理由（组件功能强大，编写又非常简单），同样也是ATL和EJB等（创建组件）编程少有人问津的原因。优点：组件编程(可复用软件模型)、由于制定了二进制标准可以在不同语言开发中使用、做到了接口与实现的分离、缩短更新周期，总之COM是更好的C++缺点(以下摘自.Net本质论)：COM（含DCOM和COM+）组件技术存在许多问题，其中有一些是关键的，有的甚至是致命的。组件技术主要强调在独立开发和部署的程序之间的一套约定（contract），COM则是微软公司将这些约定规范化的首次尝试。COM既能作为设计范例（paradigm）（它将组件的约定，表示为类型定义），也可用作支持平台技术。作为前者，COM编程模型相当成功；但是后者却存在诸多问题，正是由于缺乏稳固的平台技术，COM时代面临着终结。组件间的约定，纯粹是通过用户与组件之间的语义保证和假设的形式来表示的。但是，仍需要定义某种形式来表示语义，专业的做法是——采用可编程的类型定义，以及描述这些类型定义的人工可读文档。COM用类型的形式表示组件约定，但是该约定存在如下两个关键问题，使得其对语义的表示并不是最优的。1．约定的描述：COM没有定义约定的交换格式，即COM规范所约定的类型定义，必须通过完全是COM之外的某种技术来进行交互。微软定义和支持的COM交换格式有两个——IDL（InterfaceDefinitionLanguage接口语言定义）和TLB（TypeLiBrary类型库），但是这两种格式并不是同构的，其中也没有哪种格式是权威的或标准的。另外，COM的描述约定方式，至少还存在两个其他的关键问题：①COM缺乏对组件依赖性的描述。因此，没有办法来解析COM组件（或者其约定的定义），也不能确定它所需要的其他组件，从而无法保证它的正确运行。由于缺少相关信息，使得部署基于COM的应用程序，很难确定它需要哪些DLL，也不能静态确定所需要的是哪个版本的组件，这让对版本问题的诊断变得极其复杂；②COM约定的描述格式缺乏扩展性。2．约定的工作方式：COM组件的约定是基于类型描述的，所采用的类型系统是C++的可移植子集。而且COM对组件的约定是物理的（二进制约定）。它要求：每个方法都具有精确的虚函数表vtable偏移量、每个被传递的参数在堆栈规则中都有明确的偏移量、对象引用采用接口指针的明确格式、使用规定的分配器进行被调用这内存分配。就底层技术而言，COM组件的约定，最终只是在内存中形成堆栈结构的协议，根本没有（按组件所要求的那样来）描述语义内容。二进制的物理约定，过度关心细节，使COM难于使用和开发。尤其在针对COM组件的版本控制问题上，物理性约定所产生的问题就更大了。这使得COM组件技术，难以进行语义修改和版本升级。COM组件的约定定义的精确性，产生了高效的代码，但这却是以难以接受的不可靠性为代价。4.2002～今：.NET产生原因之二市场压力：Java的成功让微软公司感觉到了竞争的压力。读者可能多多少少已经听说或者使用过Java，Java的“一次编写，到处运行”的跨平台特性轻易地征服了很多程序员。设想一下，你在Windows平台下开发的Java程序几乎可以原封不动地在UNIX、Linux环境下运行，而如果VisualBasic在Windows平台下开发的应用程序在UNIX或者Linux上几乎无法运行，那么你为什么不想学习Java呢？.NETFramework由三个主要部门组成：公共语言运行库(CLR)、.NETFrameWork类库(统一的编程类库、或者说API)、ASP.NET。CLR为了解决COM所存在的这些问题，微软公司的COM和MTS小组，计划开发一个新的组件平台。开始时叫COM3或COM+2.0，后来又叫COR（ComponentObjectRuntime组件对象运行时）和URT（UniversalRuntime通用运行时），最后才被命名为CLR（CommonLanguageRuntime公共语言运行时[库/层]）。它是现在（由微软提交的）成为国际标准的CLI（CommonLanguageInfrastructure公共语言基础结构）在Windows平台上的一种具体实现。CLI是针对可执行代码格式、以及能执行该代码的运行时环境的一种规范。CLI标准包含如下几个主要组成部分：CTS（CommonTypeSystem公共类型系统）——被编译器、工具和CLI本身所共用的一种统一类型系统。它是一个模型，定义了在声明、使用和管理类型时，CLI应遵循的规则。CTS建立了一个框架，使跨语言集成、类型安全和高性能的代码执行成为可能；CLS（CommonLanguageSpecification公共语言规范）——语言设计者和框架（类库）设计者之间的一种协定（agreement）。它指定了CTS的一个子集和一个用法常规（usageconventions）集；metadata（元数据）——描述和引用CTS所定义类型的数据。元数据被以一种独立于任何特定的程序设计语言的方式存储。从而，元数据为操作程序的工具（如编译器和调试器）之间，以及这些工具和VES之间提供了一种公共交换机制。VES（VirtualExecutionSystem虚拟执行系统）——该系统实现和实施CTS模型。VES负责装入和运行为CLI编写的程序。它在运行时，利用元数据将分开产生的模型连接在一起，并为执行托管代码和数据提供所需要的服务。VES也被称为执行引擎；CIL（CommonIntermediateLanguage公共中间语言）——可被VES理解的指令集，也被称为MSIL（微软IL）。程序集（Assembly，装配/汇编）就是CLR中的组件，它是一种功能上不可分割的逻辑单元，由一个或多个模块（module，DLL或EXE文件）组成。大多数程序集就是一个DLL，所以程序集也被称为“托管DLL”。每个程序集中有一个程序清单（manifest），它包含了程序集内所有模块和其他文件的信息（如程序集的名称、版本号、文化和语言、程序集包含的所有文件列表、程序集所依赖的其他程序集等）。程序集中自然包含了若干CLR类的（MSIL中间语言）代码，同时还包含了这些类的元数据。元数据（metadata）描述模块中类型的相关信息，如类型的名称、类型的可见性（public或assembly）、基类、实现的接口和方法、暴露的属性、提供的事件等。CLR与COM与COM相比，CLR的组件技术有了质的飞跃，前面提到的各种COM问题都迎刃而解、一扫而光。相同点——约定（类型）与COM平台一样，CLR也注意组件间的约定，而且这些约定也是基于类型的（注意，组件技术里的类型是广义的，除了包括字符、布尔、整数和浮点数等基本数据类型之外，还包括类、结构、接口、串、数组、枚举、委托[delegate，指向方法和函数的安全指针，用于事件处理和回调]等高级结构类型）。不同点1——约定的描述（元数据）但是与COM（没有标准格式来描述约定）不同的是，CLR有完全规范的格式来描述组件之间的约定——元数据（metadata）。CLR的元数据是机器可读的，其格式是公开的、国际标准化的、完全规范的。CLR