三层架构图层解析细分

1、博客：.三层架构图ErLrti-tyWebF age/WinFormResourceAccessREMConfig AccessServiceG) nrService Entrance for .Netrvice EntityData Accessa o CDService Entrance for JavaService EntityDBService EntranceSystem boundaryService Entity三层架构图三层架构图三层架构图.系统各层次职责1.UI (User Interface )层的职责是数据的展现和采集，数据采集的结果通常以Entity object提交

2、给BL层处理。Service Interface侧层用于将业务或数据资WebServices)。2.BL ( Business Logic)层的职责是按预定的业务逻辑处理UI层提交的请求。(1) Business Function子层负责基本业务功能的实现。(2) Business Flow 子层负责将 Business Function子层提供的多个基本业务功能组织成一个完整的业务流。(Transaction只能在Business Flow子层开后3. ResourceAccess层的职责是提供全面的资源访问功能支持，并向上层屏蔽资源的来源。（1） BEM （ Business Entity

3、 Manager）子层采用 DataAccess子层和ServiceAccess子层来提供业务需要的基础数据/资源访问能力。（2） DataAccess子层负责从数据库中存取资源，并向 BEM子层屏蔽所有的 SQL语句以及数据库类型差异。DB Adapter子层负责屏蔽数据库类型的差异。ORM子层负责提供对象-关系映射的功能。Relation子层提供ORM无法完成的基于关系（Relation）的数据访问功能。（3） ServiceAccess子层用于以SOA的方式从外部系统获取资源。注：Service Entrance用于简化对 Service的访问，它相当于 Service的代理，客户直接使

4、用Service Entrance就可以访问系统发布的服务。Service E台（如Java、.Net）提供强类型的接口，内部可能隐藏了复杂的参数类型转换。（4） ConfigAccess子层用于从配置文件中获取配置object或将配置object保存倒配置文件。4. Entity侧层跨越 UI/BEM/ResourceManager层，在这些层之间传递数据。Entity侧层中包含三类 Entity ,如下图所示：EntityDE EntityConfig EntityService Entity三.AspectAspect贯穿于系统各层，是系统的横切关注点。通常采用AOP技术来对横切关注点进

5、行建模和实现。1. Securtiy Aspect:用于对整个系统的 Security提供支持。2. ErrorHandling Aspect :整个系统采用一致的错误 /异常处理方式。3. Log Aspect:用于系统异常、日志记录、业务操作记录等。四.规则1 .系统各层次及层内部子层次之间都不得跨层调用。2 . Entity object在各个层之间传递数据。3 .需要在UI层绑定到列表的数据采用基于关系的DataSet传递，除此之外，应该使用Entity object传递数据。4 .对于每一个数据库表（ Table）都有一个 DB Entity class与之对应，针对每一个Entit

6、y class都会有一个 BEM Class与之对应。5 .有些跨数据库或跨表的操作（如复杂的联合查询）也需要由相应的 BEM Class来提供支持。6 .对于相对简单的系统，可以考虑将Business Function子层和Business Flow子层合并为一个。7 . UI层和BL层禁止出现任何 SQL语句。五.错误与异常异常可以分为系统异常（如网络突然断开）和业务异常（如用户的输入值超出最大范围），业务异常必须被转化为业务执行的结果。1. DataAccess层不得向上层隐藏任何异常（该层抛出的异常几乎都是系统异常）。2 .要明确区分业务执行的结果和系统异常。比如验证用户的合法性，如果

7、对应的用户ID不存在，不应该抛出异常，而是返回（或通过out参数）一彳枚举值，这属于业务执行的结果。但是，如果在从数据库中提取用户信息时，数据库连接突然断开，则应该抛出系统异常。3 .在有些情况下，BL层应根据业务的需要捕获某些系统异常，并将其转化为业务执行的结果。比如，某个业务要求试探指定的数据库是否可连接，这 据库连接失败的系统异常转换为业务执行的结果。4 . UI层（包才Service层）除了从调用BL层白A API获取的返回值来查看业务的执行结果外，还需要截获所有的系统异常，并将其解释为友好的错误信息六.项目组织目结构以BAS系统为例。1 .主目录结构：分类而2 .命名空间命名：每个

8、dll的根命名空间即是该 dll的名字，如EAS.BL.dll的根命名空间就是 EAS.BL。每个根命名空间下面可以根据需求的 比如，EAS.BL的子空间 EAS.BL.Order与EAS.BL.Permission分别处理不同的业务逻辑。3 .包含众多子项目的庞大项目的物理组织：核心子项目Core的位置:Core子项目中包含一些公共的基础设施，如错误处理、权限控制方面等。七.发布服务与服务回调 以EAS系统为例。1 .同UI层白P Page一样，服务也不允许抛出任何异常，而是应该以返回错误码(int型，1表示成功，其它值表示失败 )的形式来表明服务调用出现了错回值，则返回值以 out参数提供

9、。2 .如果BAS系统提供了 WebService (Remoting )服务，则 BAS必须提供 BAS.Entrance.dll o BAS.Entrance.dll封装了与 BAS服务交换信息的通信机制 过BAS.Entrance.dll就可以非常简便地访问BAS提供的服务。3 .如果BAS需要通过 WebService (Remoting)回调客户系统，则必须提供仅仅定义了接口的BAS.CallBack.dll ,客户系统将引用该 dll,实现其中的接服务，供BAS回调。4 .当 WebService的参数或返回值需要是复杂类型 即架构图中的 Service Entity ,则Serv

10、ice Entity应该在对应的 BAS.EntranceParaDef.dll或BAS. 中定义。 WebService定义的方法中的复杂类型应该使用Xml字符串代替(注意， Entrance和CallBack接口对应服务的方法的参数是强类型的)，而类型对象之间的转换应当在 BAS.Entrance.dll或BAS.CallBack.dll中实现。用三层架构与设计模式思想部署企业级数据库业务系统开发1 .三层架构介绍1.1 关于架构架构这个词从它的出现后，就有许许多多的程序员、架构师们激烈地讨论着它的发展，但是架构一词的出现，却是随 着三层架构的出现才出现的。当然，目前应用三层架构开发也正是

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

12、程序要解决三个层面的问题。1.2 三层架构概述随着软件工程的不断进步和规范以及面向对象编程思想的应用，人们对封装、复用、扩展、移置等方面的要求，使 得双层架构显然更加臃月中繁琐，三层程序架构体系应运而生，可以说，三层架构体系结构是面向对象思想发展中的必然产物。当然三层架构对于目前来说早已经不是什么新鲜事物了，最早听到这个词应该是几年前使用java知道的吧，j2ee三层架构体系流行了这么多年，一直没有使用过，不过j2ee三层架构体系的提出，对软件系统的架构产生了巨大的影响， Microsoft > Boland这些公司自然不甘落后，例如 Microsoft的.net平台，更有甚者，称.ne

13、t之c#为java的儿子。那么何 谓三层架构？所谓三层架构，是在客户/服务之间加入了一个"中间层”，也叫组件层。它与客户层、服务器层共同构成 了三层体系。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有 B/S应用才有三层体系结构，三层是指逻辑上的三层。通过引入中间层，将复杂的商业逻辑从传统的双层结构 (Client-Server)应用模型中分离出来，并提供了可伸缩、 易于访问、易于管理的方法，可以将多种应用服务分别封装部署 于应用服务器，同时增强了应用程序可用性、安全性、封装复用性、可扩展性和可移置性，使用户在管理上所花费的时 间最小化，从

14、而实现了便捷、高效、安全、稳定的企业级系统应用。1.3 分层描述三层架构三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下，客户端不直 接与数据库进行交互，而是中间层向外提供接口，通过 COM/DCOM通讯或者Http等方式与中间层建立连接，再经由 中间层与数据库进行交互。当然数据通过中间层的中转无疑是降低了效率，但是它脱离于界面与数据库的完美封装，使得它的缺点显然不值得一提。典型的三层结构分为表示(presentation )层，领域(domain)层，以及基础架构(infrastructure )层，而微软的 DN磔构定义了三 个层：表示层(prese

15、ntation ),业务层(business ),和数据存储层(data access ),当然J2ee也有它不同的分法不过都大同小异 吧。既然我用.net做的开发，这大三层我无需多说了，根据我的理解，我对此做了更详细的分层，界面外观层、界面规则层、业务接口层、业务逻辑层、实体层、数据访问层、数据存储层共七层，其具体的调用如图1所示：图1由图1可以看出，虽然我将系统的架构分为七层，实际上大的方面来说，它就是一个典型的三层架构设计思想。单从这个图来看，数据的调用显得繁琐而抽象，也许这时候就会有人说，我只是想实现界面上与用户交互，然后根据用户的请求将数据读出/写 入数据库就好了，为什么要做如此复杂

16、的分层调用呢？从这个问句中我们也只看到了界面和数据库，也就是说从用户的需求来说，就是这两层而已，但是这里我们首 先要搞清楚的是三层架构它主要是为程序员为了实现部署、开发、维护企业级数据库系统而服务的。如果我们在 中间层实现了对表示层和数据库层的完全脱离，其部署、开发、维护系统的费用和时间至少降低到原来的一半，甚至更多。1.4 部署企业级数据库应用对于一个企业级数据库应用系统上的三层架构我是这样部署的：系统通过浏览器或应用程序客户端提供与用户的交互平台，并向服务器提交请求（界面外观层）；用户提交请求后，界面规则层对用户的数据按照业务逻辑层要求的接口参数封装规则封装用户数据，然后调用业务接口层对外

17、提供的相应命令接口（界面规则层），业务接口层通过对数据进行解析并分别送入不同的逻辑处理并向用户返回处理结果（业务接口层）；对于数据和命令的不同，处理方式也不同，我们将不同的处理方式都归类，并将接口层传入的数据及命令流入对应处理流程（业务规则层）；这时，不同的处理流程分析数据和命令产生出对应的一个实体，这个实体根据其本身的属性和方法以及上层传入的命令，将数据处理为数据访问层需要的接口参 数，并向数据访问层提交访问数据库的请求，并向业务接口层返回访问结果（实体层）；数据访问层会将数据转化为数据库可识别的语句（SQL）,并访问数据库层，访问结果会返回给实体层（数据访问层）；数据库层处理上层传入的SQ

18、L,读写数据库内置对象，并根据其内置对象本身的关系对数据做进一步校验和处理（数据库层）。这里我所讲到的企业级数据库应用系统，不论它是基于B/S应用系统上的三层架构设计，还是基于C/S应用系统上的三层架构设计，基本上是一样的，所不同的只是两种方式常用的数据传输协议的不同，B/S应用系统设计一般数据传递是通过HTTP来完成的，C/S应用系统设计则更多的是基于TCP/IP协议来传送数据的，当然，随着企业级应用系统对安全性方面要求的要求越来越高，更多的防火墙架设于物理线路之间，C/S应用系统的设计也越来越多地趋向于HTTP,典型的方式如：CLIENT ISAPI/CGI Server Database

19、;CLIENT Web Service Server Database;既然提到这两种方式，我简单地提一下它们两者的区别及应用，它们的不同主要是中间层向客户端提供服务的方式不同，一般情况 下这两种方式都需要架设专门用于受理客户端请求的Web Server,很明显，它更进一步地体现了三层架构的安全性。中间层基于ISAPI/CGI的方式可以说正在被 Web Service方式所取代，这也正是面向对象思想的进一步应用。ISAPI/CGI向客户端提供的服务实际上是远程调用函数，数据一般由程序员自定义结构存储，并基于 HTTP与Web Server交互，而 Web Service向客户端提供的服务是远程

20、调 用类，常常采用 XML存储数据，并基于 SOAP与Web Server交互。两者的优劣势也很明显，前者较 XML封装方式，数据量小，传输 速度快，后者因为 XML的臃肿速度上来说是它的劣势 ，不过它的安全性以及开发速度占有明显得优势。如果认真看图1中对各层的描述，不难看出，里面提到了工厂以及构造器，它是来自于设计模式中的一种思想。其中业务逻辑层的 业务规则层、实体层就是运用设计模式的思想来实现的。2 .设计模式思想的应用2.1 设计模式思想概述设计模式思想引入企业级数据库系统开发，与传统的开发模式可谓是一场革命.设计模式之于面向对象的设计与开发的作用就有如数据结构之于面向过程开发的作用一般

21、，其重要性不言而喻。当然学习设计模式的过程也是痛苦的，对于GoF的23种设计模式要一一学懂它，无疑是非常痛苦的。面 向对象系统的设计与分析实际上就是追求的两点：一是高内聚，一是低耦合。这也是我们软件设计所要追求的，无论是OO设 计中的封装、继承、多态，还是我们的设计模式的原则和实例，都是主要为了追求这两点。有人说，我们的系统小，使用设计模式会束缚我们的实现，其实不然，就如 K_Eckel在他所写的设计模式精解一书中提到的：设计模式体现的是一种思想，而思想是指导行 为的一切，理解和掌握了设计模式，并不是说记住GoF的23种设计模式的设计场景以及解决方案，而实际接受的是一种软件设计思想的熏陶和洗礼

22、，等设计模式的思想真正融入到你的思想中后，你就会不自觉得去采用设计模式的思想去设计你的系统，这才是最重要的。因此我并不想重复地去讲述这23种设计模式，更不会拘泥于其中的任何一种，我只是根据我的经验和对设计模式的思想的理解，来实现我的业务逻辑层的设计。我们在面向对象的设计中常常会遇到一些问题，比如说为了提高程序的高内聚低耦合，我们通常会抽象出一些类的公共接口以形成 抽象基类，这样我们可以为它派生很多个子类，通过申明一个抽象基类的但被实例化为指向派生类的对象，以达到多态的目的。然而当业务复杂并产生了大量的派生类时，程序员就得记住每一个派生类的名字然后New出一个指向它的指针。这就给编写程序和维护代

23、码带来了很大的困难，这种情况下我们如果要求客户端传入一个名称，我们用一个switch根据传入的名称来 New 一个子类，这就实现了中间层的封装。还有比如我的一个数据库系统中，有几百个表/视 图等对象，要对它们进行访问，如果只用面向对象的思想去操作它们，我们需要把这些数据库对象都抽象为类，封装它们自己的属性和方法，这样的工作量无疑是非常巨大的。于是我利用设计模式的思想动态地分类抽象它们，也就是说，在访问它们之前，才产生具有实体意义的类。我们可以将几十个、几百个属性、方法类同的数据库表做成一个Template Class,这样的封装方式使得代码量减少到原来的几十甚至几百分之一，而且它最大的好处是脱

24、离了数据库等等在面向对象设计中出现的问题我们大都可以用设计模式的思想去解决它，就如我们在c程序中遇到一些比较麻烦的功能时，就会想到用数据结构中的一些算法去解决它一样。2.2 数据库应用中设计模式的抽象说了这么多，我就举一个例子来说明如何在三层架构部署的企业级数据库应用系统中如何使用设计模式：数据库系统中我们最关心的就是如何操作数据库中的那些对象，我们可以将数据库中的对象看作是用来生产某一种产品的模具，每 一种类型的对象就是一种模具 ，比如表、视图、存储过程，我们可以将它们当作是三种模具，当然你可以根据业务及数据库化分的更细一 点，比如单表模具，主从表模具，视图模具、存储过程模具、数据库函数模具

25、等等，不够的你可以去继续扩展；假使我们现在有一个工厂它有好多个车间，每个车间只能够使用一种模具来生产产品，我们可以分别给它们起名字叫表车间、视图车间、存储过程车间等。当用户想要往USER表中插入一条记录的时候， 我们可以说成是在工厂要在表车间使用表模具生产出一个叫做USER的产品，然后产品进行加工 的过程。那生产并加工这个产品过程到底是怎么样的呢？这里我说明一下工厂、车间、模具、产品它们各自的功能以及在一个产品在产 生和加工过程中所处的环节，事实上根据它们的名字也不难理解。工厂：它要存贮下所有的产品名和车间名以及产品名与车间的多对一关系，用户需要知道自己要生产的产品名字是什么，工厂根据 产品名

26、来判断送交给哪个车间去处理.车间：车间使用它拥有的模具来产生一个具体产品模具：模具产生一个产品对象产品：进行自加工（插入、删除、修改、查询等 ）那么，现在我们来看看当用户通过界面层的交互，想对表USER插入一条记录的过程：事实上用户并不知道它现在操作表叫做USER,而界面层上的对象则必须知道当前操作界面所对应数据库表的名字，有了这个已知条件，界面层调用业务接口层的提供的获取表信息函数接口【例如：DataSet GetTabInfo（string _tabname ）;得到当前表的信息】，接口产生一个工厂，工厂就判断这个USER属于哪个车间生产，将USER转交给表车间，表车间产生一个表模具对象，

27、并生产出一个名叫USER的产品对象，产品对象调用自己的获取信息函数【例如：DataSet GetTabInfo（string _tabname ）;得到当前表的信息，并记录到产品对象属性中，实际上这个 GetTabInfo过程调用了数据访问层提供的花取字段信息接口】，对本身做了一次加工，也就是说此时USER这个产品已经拥有了 USER表的信息（字段、主键等），然后返回到业务接口层，业务接口层将这个具体的USER产品返回给界面层，界面层得到产品后，将数据填充到产品的属性（行和列）中，实际上就是增加一行给字段赋值的过程 ，然后再调用业务接口提供的插入数据接口【例如 ：InsertData（Data

28、Set _tabinfo）;】，同样的，接口产生工厂， 工厂找到车间，重新构造产品，产品对象对本身做插入操作，返回。这就是一个完整的操作过程。当我真正地了解了 GoF的设计模式：可复用面向对象软件的基础中的思想后，我突然发现真正如K_Eckel所说，经过了一场软件设计思想的洗礼，做系统设计时的思想发生了质的变化，封装、复用、多态、抽象 ,3 .三层架构与设计模式在 Web应用系统中的应用3.1 用c#描述系统架构设计3.1.1在.net中创建工程1）首先打开 Microsoft Visual Stdio .Net 2003,新建一个 C#项目 Web应用程序，如图 2所示:图22）在新生成的解

29、决方案中加入以下类库:GlobalDataTypeLayer:公用参数层BusinessLayer:业务逻辑层（可以将里面的四层全部分开，建成类库）DataAccessLayer:数据访问层，为了更好的扩展，我在代码表现形式上只将该层从业务逻辑层分离出来在一个命名空间中使用比较方便。UserRoleLayer命名空间中再引用各层之间互相的引用联系是BusinessLayer,BusinessLayer界面规则层可直接置于项目中，因为它是界面外观层的基类,这样的，首先要将 GlobalDataTypeLayer命名空间在其它各层全部引用，再引用DataAccessLayer。引用事例图如图3所示

30、:解决方案资源管理里 GloH口建XF 留 BusinessLoyer上各引用D System Q 5ystem,Doto rJ System.XMLAssembly Inf o.cs Fl Classl.csI-摩I DataAtcessLaysr | Fl台引用+CJ System7 System.DataQ System.XML jl AssemblylnfOnCS #1 ChssliCf之一例I Glob.alDafcaTyp&Layer i臼，回弓I用- 7 System*O System.Data:<3 System,XMLAssemblylnfo.es曾 GassL

31、cs- 聋 TestWebAp pl icat i onS- 后引用口 Assemblylnfci.es出 Global, asax.Web,config司 WebFormi aspx3.1.2应用于系统层次结构调用过程以及类的代码实现 界面表示层类图（如图4）User ServicesPHntCuntwl'A>FarmHandle : WebFormshow。Mr into PrintSetupf)Form : SyEtem.Web.ULPaqe金£求ListBuxlComboBoxl ShowObJectOSetObjectEnable ()SetOb

32、jectReadonly ()PmgeBa5HFormHandle : WebForm,yjserData : Dataset PnntCon trolHandle<<Event>> OnShow()<<E帕nt>> OnHide() iGetForrriData()<<Event>> GetForniDataf<<Event>> OnPrintC)<<Event>> QnSaveDataO <<Event >> OnSelectDataC) Free

33、()图2展示的是用户界面表示层的类图结构，图中显示了共三个类,WebForm Class 与 PrintControl Class 都属于界面外观层。WebForm Class这不仅仅表示一个类，而表示一批类，因为一般情况下与用户交流的类的属性及操作都大同小异，我们可以从一个 基类中派生，以便于编程和管理。当然如果有一些类差别比较大，可以重新概造相应的基类，重新派生，界面层的扩展可以很灵活地通 过增加基类来实现。PrintControl Class :打印控制类，主要以客户端脚本来实现，不与服务器进行数据交互，打印预览之前，打印数据应由WebForm类提交给 PrintControl。Page

34、Base Class这个类属于界面规则层， 它是 WebForm的基类，事实上界面外观与界面规则可以放在一个命名空间中，它可以是一个类，也可以是多个类，业务的复杂程度也决定了 PageBase Class的扩展，根据不同的需求可以构造相应的 WebForm基类来满足业务需 求。实现基类部分代码见附录 A. 业务逻辑层类图（如图5）Business ServicesProcedureClassBuilderViewGassBuilderBuidClassf)Build 口加篁)TabledassBQider0dassBuiderClassBuilderFa 匚 to 队 ” 一苗m

35、8口GetOassBuilder()OtherClassBuilderxltTable dbAccess<<abstract>> BuildClass()Int日后匚日ImplParamData<<Static>> GetlnstanceO Free()SelectData()SaveDatat) GetObjectlnfoO InitialConnectionf)飞<<abstract>>Entity Dat 白>daAccess : DataAccess dtTable : DataTableYi 巳 wEnti

36、tyDataTableEntityDataPr匚 2dureEntity曰 ta0 th 曰 Entity DataDataAtcess(fromi Da匕 Services)ParamData(DataSet Scl Result )ErrorStringEntityDataO<abstrdct> > Select ()<<abstract>> SaveDataO<<3bstract> > GetFieldsf)m<abstract>> GetNextlD()DBComection DBQuery Datas

37、et*SelectC) Insert ()Update () Deletef) GetTablnibO ExecuteProcediref) SelectView() ExecuteSql ()图5图5展示了复杂的业务逻辑层调用过程，其中主要展示的类有六个类，不包含派生的子类。ParamData Class公用参数类，这个类事实上并不属于三层架构中的任何层，我单独将其定义为公用参数层，它与三层架构中的任何个类都息息相关，实现代码见附录AInterfacelmpl Class是业务逻辑层向界面表示层提供的接口类，数据由界面规则层封装传入，对外接口函数根据业务需求可以增加。该类的所有函数实现基本都

38、很类似，我这里列出数据库连接和一个SaveData的代码实例，见附录AClassBuilderFactory Class工厂类，它的作用是根据接口类传入的数据找到对应的生产构造部件(ClassBuilder),这里很重要的是包含了一个简单的map,该结构在连接数据库里进行实例化，代码实现见附录AClassBuilder Class这是构造部件的抽象基类，其下可以根据业务的需求扩展很多的构件器，可以用工厂的模式理解其为构件车间， 我这里派生的构件器有：TableClassBuilder:实体表构件器ViewClassBuilder:视图构件器ProcedureClassBuilder:存储过程构

39、件器OtherClassBuilder:其它构件器基类和实体表构件器的代码实现见附录AEntityData Class这是实体类的抽象基类，其下也可以根据业务的需求扩展派生实体，前面我提到过我们的构件器与实体类是一一对应的，一个构件车间只能够生产一类产品。那么对应的派生实体就有：TableEntityData:表实体ViewEntityData:视图实体ProcedureEntityData:存储过程实体OtherClassEntityData:其它实体(这个实体的自我加工可以灵活定义)实体抽象基类及表实体的代码实现见附录ADataAccess Class是数据访问层的数据访问类，这里才真正实

40、现了数据库连接，数据库读写等，将用户的数据构造成 sql语句与数据库交互。如果想在整个系统中兼容各种数据库，那么可以将它抽象为数据访问的抽象基类，可以去派生 OracleDataAccess,SqlServerDataAccess,AccessDataAccess等等，它们的属性和方法基本上都是相同的，只是具体方法中的实现有所不同而已，访问Oracle部分实例代码见附录 A。在实例化并填充工厂MAP的时候用XML存储构件的产品名与产品类型名的多对一关系，XML结构见附录A。 数据库层数据库层指的主要是系统采用的数据库管理系统(DBMS),在整套企业级数据库应用系统中，它是最重要的

41、一环，其中主要的对象有表、视图、存储过程、函数、触发器等，数据的许多处理都应该由数据库本身去完成，例如将复杂的查询或者数据写入，都封装为存储过程和函数，将数据写入前后要进行的附加操作用触发器实现等等。对于表的创建一般应以数据库原理的第三范式规范来创建，允许一定的冗余。表及视图的创建规范直接影响到代码编写的难易度。到 这里，关于三层架构与设计模式思想部署企业级数据库应用系统开发应趋于完整了，我想主要向大家展示的实际上就是一种程 序设计的思想，不管是三层架构还是设计模式，它们都是软件工程面向对象思想的完全体现，目前，我们国家软件业相对来说是很落后的，关键的问题是软件企业的急功近利和程序员思想还停留

42、在结构化思想上，不能说你在程序中用的是类就说你的思想是面向对象，也不是说你会使用java编写程序，就说自己懂得面向对象，希望我和大家能一起进步，直正理解面向对象。参考文献1 GoF,设计模式：可复用面向对象软件的基础2 k_Eckel,设计模式精解什么是三层架构这样有利于系统的开发、维所谓的三层开发就是将系统的整个业务应用划分为表示层一一业务逻辑层一一数据访问层, 护、部署和扩展。分层是为了实现“高内聚、低耦合”。采用“分而治之”的思想，把问题划分开来各个解决，易于控制，易于延展，易 于分配资源。 表示层：负责直接跟用户进行交互，一般也就是指系统的界面， 用于数据录入，数据显示等。意味着只做与

43、外观显示相关的工作，不属于他的工作不用做。 业务逻辑层：用于做一些有效性验证的工作，以更好地保证程序运行的健壮性。如完成数据添加、修改和查询业务等；不允许指 定的文本框中输入空字符串，数据格式是否正确及数据类型验证；用户的权限的合法性判断等等，通过以上的诸多判断以决定是否将操作继续向后传递，尽量保证程序的正常运行。 数据访问层：顾名思义，就是用于专门跟数据库进行交互。执行数据的添加、删除、修改和显示等。需要强调的是，所有的数据 对象只在这一层被引用，如System.Data.SqlClient等，除数据层之外的任何地方都不应该出现这样的引用。ASP.NEK以使用.NET平台快速方便地部署三层架

44、构。ASP.NE砰命性的变化是在网页中也使用基于事件的处理，可以 指定处理的后台代码文件， 可以使用C供VB C+拜口 J#作为后台代码的语言。.NET中可以方便的实现组件的装配， 后台代码通过命名空间可以方便的使用自己定义的组件。显示层放在ASPXJ面中，数据库操作和逻辑层用组件或封装类来 实现，这样就很方便的实现了三层架构。2 .为什么使用三层架构对于一个简单的应用程序来说，代码量不是很多的情况下，一层结构或二层结构开发完全够用，没有必要将其复杂化， 如果对一个复杂的大型系统，设计为一层结构或二层结构开发，那么这样的设计存在很严重缺陷。下面会具体介绍，分 层开发其实是为大型系统服务的。在开

45、发过程中，初级程序人员出现相似的功能经常复制代码， 那么同样的代码为什么要写那么多次？不但使程序变得冗 长，更不利于维护，一个小小的修改或许会涉及很多页面，经常导致异常的产生使程序不能正常运行。最主要的面向对象的思想没有得到丝毫的体现，打着面向对象的幌子却依然走着面向过程的道路。意识到这样的问题，初级程序人员开始将程序中一些公用的处理程序写成公共方法，封装在类中，供其它程序调用。例如写一个数据操作类，对数据操作进行合理封 装，在数据库操作过程中，只要类中的相应方法（数据添加、修改、查 询等）可以完成特定的数据操作，这就是数据访问层，不用每次操作数据库时都写那些重复性的数据库操作代码。在新的应用

46、开发中，数据访问层可以直接拿来用。面向对象的三大特性之一的封装性在这里得到了很好的体现。读者现在似乎找到了面向对象的 感觉，代码量较以前有了很大的减少，而且修改的时候也比较方便，也实现了代码的重用性。卜面举两个案例，解释一下为什么要使用三层架构 案例一：数据库系统软件由于数据量的不断增加，数据库由Access变成了 SQL Server数据库，这样原来的数据访问层失效了，数据操作对象发生了变化，并且页面中涉及数据对象的地方也要进行修改，因为原来可能会使用OleDbDataReader对象将数据传递给显示页面，现在都得换成SqlDataReader对象，SQLServer和Access支持的数据

47、类型也不一致，在显示数据时进行的数据转换也要进行修改，这是其中一种情况。案例二：由于特殊情况需要，把Web形式的项目改造成 Windows应用，此时需要做多少修改呢？如果在 Aspx.cs中占据了大量代 码，或者还有部分代码存在于 Aspx中，那么整个系统是否需要重新来开发呢？在上面的案例中是否体会到了没有分层开发模式的缺陷呢？是否碰到过这样的情况呢？这都是由设计不合理造成的，多层开发架构的出现可以很好地解决该问题，通过程序架构进行合理的分层，将极大地提高程序的通用性。3 .使用三层架构开发的优点使用三层架构开发有以下优点： 从开发角度和应用角度来看，三层架构比二层架构或单层架构都有更大的优势

48、。三层架构适合团队开发，每人可以有不同的分工，协同工作使效率倍增。开发二层或单层应用程序时，每个开发人员都应对系统有较深的理解，能力要求很高，开发三层应用程序时，则可以结合多方面的人才，只需少数人对系统全面了解即可，从一定程度降低了开发的难度。 三层架构可以更好的支持分布式计算环境。逻辑层的应用程序可以在多个计算机上运行，充分利用网络的计算功能。分布式计算的潜力巨大，远比升级 CPU有效。美国人曾利用分式计算解密，几个月就破解了据称永远都破解不了的密码。 三层架构的最大优点是它的安全性。用户只能通过逻辑层来访问数据层，减少了入口点，把很多危险的系统功能都屏蔽了。4 .三层架构的种类目前，团队开

49、发人员在开发项目时，大多都使用分层开发架构设计，最常见的就是三层架构，目的在于使各个层之间只 能够被它相邻的层产生影响，但是这个 限制常常在使用多层开发的时候被违反，这对系统的开发是有害的。三层架构 按驱动模式可划分三种：数据层驱动模式、陈述层驱动模式和隔离驱动模式，其中隔离驱动模式开发最为重要。下面通过三种模式的对比，介绍隔离驱动模式的重要性。数据层驱动模式所谓的数据层驱动模式，就是先设计数据层，陈述层围绕数据层展开，一旦完成了数据层和陈述层，业务层就围绕 数据层展开。因为陈述层是围绕数据层展开的，这将会使陈述层中的约束不准确，并且限制了业务层的变更。由于业务层受到限制，一些简单变化可以通过

50、 SQLS询和存储过程来实现。这种模式非常的普遍，它和传统的客户服务端开发相似，并且是围绕已经存在的数据库设计的。由于陈述层是围绕 数据层设计的，它常常是凭直觉模仿数据层的实际结构。常常存在一种额外的反馈循环在陈述层到数据之间，当在设计陈述层不容易实现的时候常常会去修改数据层，也就形成了这种反馈循环。开发者请求修改数据库方便陈述层的开发，但是对数据层的设计却是有害的。这种改变是人为的而没考虑到其他需求的限制。这种修改经常会违反至少损害数据的特有规则，导致不必要的数据冗余和数据的非标准化。陈述层驱动模式陈述层驱动模式是数据层围绕陈述层展开的。业务层的完成一般是通过简单的SQLS询和很少的变化或者

51、隔离。由于数据库的设计是为了陈述层的方便， 并非从数据层设计方面考虑，所以数据库的设计在性能上通常很低。陈述层驱动模式设计图如图1.6所示。隔离驱动模式用隔离驱动模式设计，陈述层和数据层被独立的开发，常常是平行开发。这两层在设计时没有任何的相互干扰，所 以不会存在人为的约束和有害的设计元素。当两层都设计完成后，再设计业务层。业务层的责任就是在没有对数据层和陈述层的需求变化的基础上完成所有的转换。陈述层驱动模式设计。因为现在陈述层和数据层是完全独立的， 当业务层需求改变的时候，陈述层和数据层都可以做相应的修改而不影响 对方。改变两个在物理上不相邻的层不会直接对其他层产生影响或发生冲突。这就允许数

52、据层结构的调整或者陈述层根据用户的需求做相应的变化，而不需要系统做大的调整或者修改。表 1.1将对这3种驱动模式 进行对比。表种驱动模式对比答据层驱动模式陈述层驱动模式隔离驱动模式数据库(1)很容易设计(2)产生负面影响(3)很难改变数据层， 因为它和陈述层紧密绑(D数据库设计很糟(2)严重的不规范化 设计(3)其他系统不易使 用(4)很难改变数据层， 由于它跟陈述层紧密 绑定(1)优化设计(2)集中设计数据 库，陈述层对它影 响很小业务需求,常不能适应业务需求,化常常适应业务需求变 化适应需求及化用户界面,围绕数据层面/、是围*用户，不易修改适合用户扩展界面适合用户扩展界面扩展性通常可扩张，

53、但是常常在 M户界面需要比较多的 小写以满足数据库的结 构，同时数据库可能需要完整性的扩张很难，常 常只有通过“剪切，粘 贴”函数来实现很容易扩展存储一些冗余的字段综上所述，很容易看出隔离驱动模式的优点，隔离驱动*II式设计可以极大地提高程序的扩展性。在1.3.2节中的应用中就采用了三层架构的隔离驱动模式。三层结构设计与ERPFB署规划金蝶（中国）产品经理尚强互联网周刊随着信息技术的飞速发展和企业信息化建设的迅猛推进，越来越多的企业都在积极选择引进实施 ER味提升自身的 竞争力。在ERP勺项目执行过程中，如何 根据企业的需求，结合 ERR品的应用，在基于企业Intranet和Extranet

54、构成的混合网络中有效实施部署 ERFT品，是现代企业信息管理责任 部门正面临的一项艰巨的任务。必须指出：合理的规划部署，不仅仅直接影响到ERP产品各项管理功能的有效实现，更直接决定着整个ERP系统的 运行性能。在对 国内众多ERF®施企业进行调研的过程中，我们发现相当多的企业ERP系统或多或少都存在着性能瓶颈，这一方面固然和选择的产品本身性能有关，另一方面也与企业对ERFT品的部署规划缺乏应有的了解和重视有重要的关系。复杂应用系统的解决之道-三层结构设计业界当前比较成熟的解决方案是三层结构设计，例如基于微软体系架构的金蝶K/3 ERP系统就是使用典型的Windows DN2层体系结构

55、。它具有数据访问安全性增强的事物对象管理高可用性强大的可扩展性等突出特点。特别是在可扩展性方面，K/3 ERP的三层体系结构体现了业界倡导的自由扩展方案技术精髓，它可以允许用户针对 不同业务复杂状况对K/3系统运算负荷能力的需求而在方案中做灵活的扩展处理。从上图我们可以看到，三层结构设计中，ERP产品可以划分为至少三个逻辑层：Presentation （表示层）、Business Logic （业务逻辑层）、Data （数据层）。表示层就是我们通常讲的客户端，它可以是32位的Windows界面客户端，也可以是基于浏览器的瘦客户 端；数据层就是对应于专业的数据库服务，例如： Oracle/DB2

56、/SQL Server等）；业务逻 辑层则集中体现了 ERFT商的产品功能，通常又被称为中间层。表示服务层负责：-从用户收集信息- 将用户信息发送到业务服务层做处理- 从业务服务层接收处理结果- 将结果显示给用户业务服务层负责：- 从表示层接收输入- 与数据层交互执行已设计的业务操作（业务逻辑，系统服务等）- 将处理结果发送到表示层。数据服务层负责：- 数据存储- 数据获取- 数据维护- 数据完整性基于三层结构的ERPSB署规划设计我们看到，三层结构下的ER网划，从本质上讲就是如何对客户端主机、业务逻辑层服务器、数据库服务器进行规 划部署的过程。企业的需求 并不是一成不变的，一方面，企业伴随着成长发展，需求一定会发生增长；另一方面，成 熟的企业ERFffi常会选择“整体规划，分步实施”的发展策略。因此负责 的ER啾件厂商应该并且能够预见到企业的 需求扩展同时在部署方案设计上予以体现和支持。下面我们就从一个企业的模拟案例出发， 看看分层结构的ERPfe