重读《COM原理与应用》之一——多层软件结构（13.3）

      随着.Net的面世，现在真正能静下心来学习有关COM技术的人已经少之又少，包括自己。总觉得对付工作中一些业务相关的开发，只要了解最新的开发平台和开发技术就已经足够了。确实随着技术不断地更新换代，不断地包装，隐藏了许多和业务不相关的内幕技术和原理，让人变得幸福而懒惰。但是，对于一个真正想Trace Fact的程序员来说，掌握这些往往会在出现系统异常或者在调试跟踪到没有源代码时，显得格外地无助，仿佛程序已不为自己所控，难听点就是任人宰割。因此，这些日子又想把以前的一些好书翻出来，重新研究下，学生时代看只是粗粗地看个懵懂，这次希望加上这几年来的工作经验来重新挖掘下这本好书深处隐藏的瑰宝。另，也想做出笔记和摘录以便下次再想翻看时，可以有个提纲挈领之效。

      潘老师的这本《COM原理与应用》，确实值得大家多次翻阅，其中一些原理总结得颇为到位。可能和大家看书的习惯不同，又或以对该书有了一个大致的了解，此次，并未从第一章开始阅读，而是从和本人目前实际工作中一些体会较深联系较紧密的第13章中的第3节多层软件结构开始。

 

     现在开始，废话少说，可能有些内容较肤浅，可跳过。（图请参见书的相关页码）

     一谈多层软件结构，就会联想到什么两、三或多层CS或BS或MS（Mobile System）架构。没错，不管是单层、两层、三层还是多层软件结构，都会包括以下几项内容：用户界面、业务逻辑以及数据维护。这三项内容是目前软件（不包括控制台程序）所必不可少的，不管你用什么技术、用什么平台、用什么语言，你开发或编写的程序都不跳出这个圈子。

     有了这点认识，那单层、两层、三层还是多层都是不难理解的。

     单层就是眉毛胡子一把抓，所有这三项内容都在一个应用程序搞定。比如，Microsoft Word就是典型的单层应用软件，既有用户界面，又包括业务规则（分页、样式处理），还包括文档数据的维护，所有这些构成Word的应用整体（P428）。单层也有优点，很明显它的运行效率相对较高，响应交互较快（都在一个程序内）。

     当网络应用与分布式应用出现时，纵使开发再牛的单层也无法满足需求了，两层就应运而生。但是针对三项内容，两层就必须有所分了。业务逻辑中间层需要有选择的放：可以与用户界面放在一起，也可以与数据维护放在一起，因此也就有了胖客户端和廋客户端的概念。（与数据维护放一起时，我们经常会采用存储过程来实现业务逻辑）

     三层就自然了，对应就比较清晰了。因此，也是目前流行的架构。又更明确的层名：表现层、业务层、数据层。

     三层之上，就要看需求了，在一些专业的需求中可能会用到更多层。举个例子，结合目前最流行的一些开发平台和语言：采用SQL Server来维护数据层，采用CSharp或VB或JAVA来实现业务逻辑模型，采用WebServices来进行某些业务逻辑的封装形成中间层，采用Flex来做表现层。此处的这个结构可能原先一直做CS系统而后转向BS开发的同志一定会深有体会，只要CS程序结构足够清晰，接口标准规范，完全可以原封不动作为业务逻辑层，然后通过WebServices来包装来发布一些可供调用的功能，另外，WebServices作为业界的标准，各种脚本语言的开发平台（如Flex）都提供方便的调用模式。

     回到COM来，COM基础上的三层结构，层层之间都是通过COM接口来联系的，表现层与业务层往往不在同一机器上，通过DCOM来访问业务层，业务层与数据层之间也需要通过ODBC（现在的学生应该不常听到了）或者OLEDB对象来连接。

     最后说一说，表现层的客户应用不一定是专门开发的应用程序，也可以把应用嵌入到别的应用程序，两种情况：

     1.VBA应用程序，如 内嵌到Word、Excel的VBA程序，也可以调用一般的COM对象（包括OLE自动化对象）。

     2.网页脚本程序，如 采用VBScript、JavaScript脚本语言，内嵌一些用户交互到网页中。

 

     下次总结：13.4 用COM设计Web应用