l.Net本质论中文版.docVIP

第一章　CLR是一个更好的COM 我的第一部书是《Essential COM》（Addison-Wesley出版，1998年）。它首先描述了困扰前COM世界的问题，继而引出了COM这种新的架构，以解决这些难题。由于CLR与COM有着某种密不可分的继承关系，因此让这本书与《Essential COM》有一个类似的开头比较合适。不同的是，我们这次将考察一个COM已经成型的世界。 COM回顾 组件技术主要强调独立开发和部署的程序之间的约定（contract）。组件对象模型[Component Object Mode(COM)]是Microsoft公司首次尝试将这些约定规范化。这样，它们既能作为设计范例（design paradigm），也能用作支持的平台技术（supporting platform technology）。COM的设计范例就是将组件约定表示为类型定义（type definition）。而在COM出现以前，约定仅仅表现为简单的函数入口点，于是COM从以前的世界跨出了一大步。在这个方面，COM是个重大的进步，它将动态加载代码和类型系统以相当一致的方式有机结合在一起。  COM编程模型本身极好地经受住了时间的考验。COM将很多现有的思想，例如，封装（encapsulation）、多态（polymorphism），以及接口与实现分离等等，融合进统一的编程规范，这在软件工程领域留下了不可磨灭的印记。这里，我不想重复阐述COM模型，有关内容你可以参考《Essential COM》或者《Design Patterns》（Erich Gamma等著，Addison-Wesley出版，1995年）的第一章。尽管它们在表述上相差甚远，但本质上都是指相同的编程模型。 COM既是编程模型，也是支持的平台技术。对于后者，COM做得就不如我所喜爱的编程模型那样棒。遗憾的是，还需要一个稳固的平台技术，使COM不只是一个理念或者编程准则。正是因为这方面的原因，COM时代面临着终结。 多数COM平台的问题都能追溯到组件（component）间约定的本性上。在理想世界中，组件间的约定纯粹是通过用户与组件之间的语义保证和假设的形式表示的。不过，软件工程领域仍然要定义某种形式来表示语义，并且，它是已经被证明，对于大范围工业界的部署在商业上（或者技术上）是可行的。最接近的专业做法是采用可编程的类型定义，以及描述那些类型定义的人工可读的（human-readable）文档。这是COM以前的做法，也是最后一个COM组件消失后的做法。 COM用类型的形式表示组件约定；不过，COM的组件约定存在两个关键问题，使得基于COM的约定技术对表示语义并不是最优的。其中，一个问题与COM约定的描述有关；另一个则与约定本身有关。 COM的第一个问题来自约定的描述。COM规范特别避免强制用于约定定义的交换格式。这意味着如果只遵循COM规范，就无法以标准化的方式描述约定；准确地说，COM规范假定约定的类型定义之间将通过完全是COM之外的某种技术进行交互。当然，这只有在规范的世界里才行之有效。为了使COM成为有用的技术，就需要具体的解决方案；否则，构建编译器、工具和支撑架构都是不可能的。  对于约定描述，Microsoft定义和支持的COM交换格式不是一个，而是两个：接口定义语言[Interface Definition Language(IDL)]和类型库[type library(TLB)]文件。这似乎没有什么问题；但是，两种格式并不是同构的（isomorphic）。也就是说，其中一种格式表示的结构，对另一种格式没有什么意义。更糟的是，某种格式所支持的结构无法成为其他格式支持结构的子集。因此，对约定描述而言，无法确定哪种格式是“权威的”或者“标准的”。 有人主张简单地定义第三种格式，并以它来支持其他两种格式都支持的所有构件。然而，在COM中，描述约定的方式还存在其他至少两个关键问题。其中一个就是COM没有描述组件的依赖性（dependency）。直到撰写本书时，还是没有办法解析COM组件（或者它的约定定义），以及确定它所需要的其他组件，以保证它的正确运行。由于缺乏相关信息，使得在部署基于COM的应用程序时，很难确定采用哪些DLL。此外，静态地确定需要哪个版本的组件也是不可能的，这使诊断版本问题变得极其困难。 第二个主要问题，也是敲响COM约定描述格式最终丧钟的，就是缺乏扩展性。早在九十年代，Microsoft事务服务器[Microsoft Transaction Server(MTS)]开发小组正致力于一种新的编程模型，它是基于现在被称为面向方面 [aspect-orient programming(AOP)]的编程思想。AOP获取非特定域（not domain-specif