三层架构与设计模式思想

三层架构与设计模式思想 _lxp 1关于架构

架构这个词从它的出现后,就有许许多多的程序员、架构师们激烈地讨论着它的发展，但是架构一词的出现，却是随着三层架构的出现才出现的。当然，目前应用三层架构开发也正是业界最关注的主题。那么这里我们来看看单层、双层、三层甚至多层架构到底是怎么一回事。单层结构是80年代以来小型应用的结构，在那个结构化编程充斥的时代，还没有出现架构的概念，典型的是基于Dbase、Foxbase等小型数据库的应用。双层结构的同义词可以理解为传统的客户/服务器结构，尽管目前占统治地位的结构，但是其封装移植等方面的缺陷，已使它步入暮年，典型是基于Oracle、Infomix等大型数据库的C/S应用。三层结构是传统的客户/服务器结构的发展，代表了企业级应用的未来，典型的有Web下的应用。多层结构和三层结构的含义是一样的，只是细节有所不同。之所以会有双层、三层这些提法，是因为应用程序要解决三个层面的问题。

1.2三层架构概述随着软件工程的不断进步和规范以及面向对象编程思想的应用，人们对封装、复用、扩展、移置等方面的要求，使得双层架构显然更加臃肿繁琐，三层程序架构体系应运而生，可以说，三层架构体系结构是面向对象思想发展中的必然产物。当然三层架构对于目前来说早已经不是什么新鲜事物了,最早听到这个词应该是几年前使用java知道的吧， j2ee三层架构体系流行了这么多年，一直没有使用过,不过j2ee三层架构体系的提出，对软件系统的架构产生了巨大的影响，Microsoft、Boland这些公司自然不甘落后，例如Microsoft的.net平台，更有甚者，称.net之c#为java的儿子。那么何谓三层架构？所谓三层架构，是在客户/服务之间加入了一个"中间层"，也叫组件层。它与客户层、服务器层共同构成了三层体系。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才有三层体系结构，三层是指逻辑上的三层。通过引入中间层，将复杂的商业逻辑从传统的双层结构(Client-Server)应用模型中分离出来，并提供了可伸缩、易于访问、易于管理的方法，可以将多种应用服务分别封装部署于应用服务器，同时增强了应用程序可用性、安全性、封装复用性、可扩展性和可移置性，使用户在管理上所花费的时间最小化，从而实现了便捷、高效、安全、稳定的企业级系统应用。

1.3分层描述三层架构三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下，客户端不直接与数据库进行交互，而是中间层向外提供接口，通过COM/DCOM通讯或者Http等方式与中间层建立连接，再经由中间层与数据库进行交互。当然数据通过中间层的中转无疑是降低了效率，但是它脱离于界面与数据库的完美封装，使得它的缺点显然不值得一提。 典型的三层结构分为表示（presentation）层, 领域（domain）层, 以及基础架构（infrastructure）层，而微软的DNA架构定义了三个层：表示层（presentation），业务层（business），和数据存储层（data access），当然J2ee 也有它不同的分法不过都大同小异吧。既然我用.net做的开发，这大三层我无需多说了,根据我的理解，我对此做了更详细的分层,界面外观层、界面规则层、业务接口层、业务逻辑层、实体层、数据访问层、数据存储层共七层，其具体的调用如图1所示: 图1由图1可以看出，虽然我将系统的架构分为七层，实际上大的方面来说，它就是一个典型的三层架构设计思想。单从这个图来看，数据的调用显得繁琐而抽象，也许这时候就会有人说，我只是想实现界面上与用户交互，然后根据用户的请求将数据读出/写入数据库就好了，为什么要做如此复杂的分层调用呢？从这个问句中我们也只看到了界面和数据库，也就是说从用户的需求来说，就是这两层而已，但是这里我们首先要搞清楚的是三层架构它主要是为程序员为了实现部署、开发、维护企业级数据库系统而服务的。如果我们在中间层实现了对表示层和数据库层的完全脱离，其部署、开发、维护系统的费用和时间至少降低到原来的一半，甚至更多。

1.4部署企业级数据库应用对于一个企业级数据库应用系统上的三层架构我是这样部署的：系统通过浏览器或应用程序客户端提供与用户的交互平台，并向服务器提交请求（界面外观层）；用户提交请求后，界面规则层对用户的数据按照业务逻辑层要求的接口参数封装规则封装用户数据，然后调用业务接口层对外提供的相应命令接口（界面规则层），业务接口层通过对数据进行解析并分别送入不同的逻辑处理并向用户返回处理结果(业务接口层)；对于数据和命令的不同，处理方式也不同，我们将不同的处理方式都归类，并将接口层传入的数据及命令流入对应处理流程（业务规则层）；这时，不同的处理流程分析数据和命令产生出对应的一个实体，这个实体根据其本身的属性和方法以及上层传入的命令，将数据处理为数据访问层需要的接口参数，并向数据访问层提交访问数据库的请求，并向业务接口层返回访问结果（实体层）；数据访问层会将数据转化为数据库可识别的语句（SQL），并访问数据库层，访问结果会返回给实体层（数据访问层）；数据库层处理上层传入的SQL，读写数据库内置对象，并根据其内置对象本身的关系对数据做进一步校验和处理（数据库层）。这里我所讲到的企业级数据库应用系统，不论它是基于B/S应用系统上的三层架构设计，还是基于C/S应用系统上的三层架构设计，基本上是一样的，所不同的只是两种方式常用的数据传输协议的不同，B/S应用系统设计一般数据传递是通过HTTP来完成的，C/S应用系统设计则更多的是基于TCP/IP协议来传送数据的，当然，随着企业级应用系统对安全性方面要求的要求越来越高，更多的防火墙架设于物理线路之间，C/S应用系统的设计也越来越多地趋向于HTTP，典型的方式如： CLIENTàISAPI/CGIàServer Database； CLIENTàWebServiceàServer Database；既然提到这两种方式，我简单地提一下它们两者的区别及应用，它们的不同主要是中间层向客户端提供服务的方式不同，一般情况下这两种方式都需要架设专门用于受理客户端请求的Web Server，很明显，它更进一步地体现了三层架构的安全性。中间层基于ISAPI/CGI的方式可以说正在被Web Service方式所取代，这也正是面向对象思想的进一步应用。ISAPI/CGI向客户端提供的服务实际上是远程调用函数，数据一般由程序员自定义结构存储，并基于HTTP与Web Server交互，而Web Service向客户端提供的服务是远程调用类，常常采用XML存储数据，并基于SOAP与Web Server交互。两者的优劣势也很明显，前者较XML封装方式，数据量小，传输速度快，后者因为XML的臃肿速度上来说是它的劣势,不过它的安全性以及开发速度占有明显得优势。如果认真看图1中对各层的描述，不难看出，里面提到了工厂以及构造器，它是来自于设计模式中的一种思想。其中业务逻辑层的业务规则层、实体层就是运用设计模式的思想来实现的。

2. 设计模式思想的应用 2.1设计模式思想概述设计模式思想引入企业级数据库系统开发，与传统的开发模式可谓是一场革命.设计模式之于面向对象的设计与开发的作用就有如数据结构之于面向过程开发的作用一般，其重要性不言而喻。当然学习设计模式的过程也是痛苦的，对于GoF的23种设计模式要一一学懂它，无疑是非常痛苦的。面向对象系统的设计与分析实际上就是追求的两点：一是高内聚，一是低耦合。这也是我们软件设计所要追求的，无论是ＯＯ设计中的封装、继承、多态，还是我们的设计模式的原则和实例，都是主要为了追求这两点。有人说，我们的系统小，使用设计模式会束缚我们的实现，其实不然，就如K_Eckel在他所写的《设计模式精解》一书中提到的：设计模式体现的是一种思想，而思想是指导行为的一切，理解和掌握了设计模式，并不是说记住GoF的23种设计模式的设计场景以及解决方案，而实际接受的是一种软件设计思想的熏陶和洗礼，等设计模式的思想真正融入到你的思想中后，你就会不自觉得去采用设计模式的思想去设计你的系统，这才是最重要的。因此我并不想重复地去讲述这23种设计模式，更不会拘泥于其中的任何一种，我只是根据我的经验和对设计模式的思想的理解，来实现我的业务逻辑层的设计。我们在面向对象的设计中常常会遇到一些问题，比如说为了提高程序的高内聚低耦合，我们通常会抽象出一些类的公共接口以形成抽象基类，这样我们可以为它派生很多个子类,通过申明一个抽象基类的但被实例化为指向派生类的对象，以达到多态的目的。然而当业务复杂并产生了大量的派生类时，程序员就得记住每一个派生类的名字然后New出一个指向它的指针。这就给编写程序和维护代码带来了很大的困难，这种情况下我们如果要求客户端传入一个名称，我们用一个switch根据传入的名称来New一个子类，这就实现了中间层的封装。还有比如我的一个数据库系统中，有几百个表/视图等对象，要对它们进行访问，如果只用面向对象的思想去操作它们，我们需要把这些数据库对象都抽象为类，封装它们自己的属性和方法，这样的工作量无疑是非常巨大的。于是我利用设计模式的思想动态地分类抽象它们，也就是说，在访问它们之前，才产生具有实体意义的类。我们可以将几十个、几百个属性、方法类同的数据库表做成一个Template Class,这样的封装方式使得代码量减少到原来的几十甚至几百分之一，而且它最大的好处是脱离了数据库… …等等在面向对象设计中出现的问题我们大都可以用设计模式的思想去解决它，就如我们在c程序中遇到一些比较麻烦的功能时，就会想到用数据结构中的一些算法去解决它一样。

2.2数据库应用中设计模式的抽象说了这么多，我就举一个例子来说明如何在三层架构部署的企业级数据库应用系统中如何使用设计模式：数据库系统中我们最关心的就是如何操作数据库中的那些对象，我们可以将数据库中的对象看作是用来生产某一种产品的模具，每一种类型的对象就是一种模具,比如表、视图、存储过程，我们可以将它们当作是三种模具，当然你可以根据业务及数据库化分的更细一点，比如单表模具，主从表模具，视图模具、存储过程模具、数据库函数模具等等，不够的你可以去继续扩展;假使我们现在有一个工厂,它有好多个车间，每个车间只能够使用一种模具来生产产品,我们可以分别给它们起名字叫表车间、视图车间、存储过程车间等。当用户想要往USER表中插入一条记录的时候，我们可以说成是在工厂要在表车间使用表模具生产出一个叫做USER的产品,然后产品进行加工的过程。那生产并加工这个产品过程到底是怎么样的呢？这里我说明一下工厂、车间、模具、产品它们各自的功能以及在一个产品在产生和加工过程中所处的环节，事实上根据它们的名字也不难理解。工厂：它要存贮下所有的产品名和车间名以及产品名与车间的多对一关系，用户需要知道自己要生产的产品名字是什么，工厂根据产品名来判断送交给哪个车间去处理. 车间：车间使用它拥有的模具来产生一个具体产品模具：模具产生一个产品对象产品：进行自加工(插入、删除、修改、查询等) 那么，现在我们来看看当用户通过界面层的交互，想对表USER插入一条记录的过程：事实上用户并不知道它现在操作表叫做USER,而界面层上的对象则必须知道当前操作界面所对应数据库表的名字，有了这个已知条件,界面层调用业务接口层的提供的获取表信息函数接口【例如：DataSetGetTabInfo(string _tabname）;//得到当前表的信息】，接口产生一个工厂，工厂就判断这个USER属于哪个车间生产，将USER转交给表车间，表车间产生一个表模具对象，并生产出一个名叫USER的产品对象,产品对象调用自己的获取信息函数【例如：DataSetGetTabInfo(string _tabname）;//得到当前表的信息，并记录到产品对象属性中,实际上这个GetTabInfo过程调用了数据访问层提供的花取字段信息接口】,对本身做了一次加工，也就是说此时USER这个产品已经拥有了USER表的信息(字段、主键等),然后返回到业务接口层，业务接口层将这个具体的USER产品返回给界面层，界面层得到产品后，将数据填充到产品的属性(行和列)中，实际上就是增加一行给字段赋值的过程,然后再调用业务接口提供的插入数据接口【例如:InsertData(DataSet _tabinfo);】,同样的，接口产生工厂，工厂找到车间，重新构造产品，产品对象对本身做插入操作,返回。这就是一个完整的操作过程。当我真正地了解了GoF的《设计模式：可复用面向对象软件的基础》中的思想后，我突然发现真正如K_Eckel所说，经过了一场软件设计思想的洗礼，做系统设计时的思想发生了质的变化，封装、复用、多态、抽象……