《三层架构图层解析[细分].docx》由会员分享，可在线阅读，更多相关《三层架构图层解析[细分].docx（35页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、一三层架构图三层架构图三层架构图三层架构图二系统各层次职责1.UIUser Interface层职责是数据展现和采集，数据采集结果通常以Entity object提交给BL层处理。Service Interface侧层用于将业务或数据资源发布为效劳如WebServices。2.BLBusiness Logic层职责是按预定业务逻辑处理UI层提交请求。1Business Function 子层负责根本业务功能实现。2Business Flow 子层负责将Business Function子层提供多个根本业务功能组织成一个完整业务流。Transaction只能在Business Flow 子层开启
2、。3ResourceAccess层职责是提供全面资源访问功能支持，并向上层屏蔽资源来源。1BEMBusiness Entity Manager子层采用DataAccess子层和ServiceAccess子层来提供业务需要根底数据/资源访问能力。2DataAccess子层负责从数据库中存取资源，并向BEM子层屏蔽所有SQL语句以及数据库类型差异。DB Adapter子层负责屏蔽数据库类型差异。ORM子层负责提供对象关系映射功能。Relation子层提供ORM无法完成基于关系Relation数据访问功能。3ServiceAccess子层用于以SOA方式从外部系统获取资源。注：Service Ent
3、rance用于简化对Service访问，它相当于Service代理，客户直接使用Service Entrance就可以访问系统发布效劳。Service Entrance为特定平台如Java、.Net提供强类型接口，内部可能隐藏了复杂参数类型转换。4ConfigAccess子层用于从配置文件中获取配置object或将配置object保存倒配置文件。4Entity侧层跨越UI/BEM/ResourceManager层，在这些层之间传递数据。Entity侧层中包含三类Entity，如下列图所示：三AspectAspect贯穿于系统各层，是系统横切关注点。通常采用AOP技术来对横切关注点进展建模和实现
4、。1Securtiy Aspect：用于对整个系统Security提供支持。2ErrorHandling Aspect：整个系统采用一致错误/异常处理方式。3Log Aspect：用于系统异常、日志记录、业务操作记录等。四规那么1系统各层次及层内部子层次之间都不得跨层调用。2Entity object 在各个层之间传递数据。3需要在UI层绑定到列表数据采用基于关系DataSet传递，除此之外，应该使用Entity object传递数据。4对于每一个数据库表Table都有一个DB Entity class与之对应，针对每一个Entity class都会有一个BEM Class与之对应。5有些跨数
5、据库或跨表操作如复杂联合查询也需要由相应BEM Class来提供支持。6对于相对简单系统，可以考虑将Business Function子层和Business Flow 子层合并为一个。7UI层和BL层制止出现任何SQL语句。五错误与异常 异常可以分为系统异常如网络突然断开和业务异常如用户输入值超出最大范围，业务异常必须被转化为业务执行结果。1DataAccess层不得向上层隐藏任何异常该层抛出异常几乎都是系统异常。2要明确区分业务执行结果和系统异常。比方验证用户合法性，如果对应用户ID不存在，不应该抛出异常，而是返回或通过out参数一个表示验证 结果枚举值，这属于业务执行结果。但是，如果在从数
6、据库中提取用户信息时，数据库连接突然断开，那么应该抛出系统异常。3在有些情况下，BL层应根据业务需要捕获某些系统异常，并将其转化为业务执行结果。比方，某个业务要求试探指定数据库是否可连接，这时BL就需要将数据库连接失败系统异常转换为业务执行结果。4UI层(包括Service层)除了从调用BL层API获取返回值来查看业务执行结果外，还需要截获所有系统异常，并将其解释为友好错误信息呈现给用户。六工程组织目构造以BAS系统为例。1主目录构造：2命名空间命名：每个dll根命名空间即是该dll名字，如EAS.BL.dll根命名空间就是EAS.BL。每个根命名空间下面可以根据需求 分类而增加子命名空间，比
7、方，EAS.BL子空间EAS.BL.Order与EAS.BL.Permission分别处理不同业务逻辑。3.包含众多子工程庞大工程物理组织：核心子工程Core位置：Core子工程中包含一些公共根底设施，如错误处理、权限控制方面等。七发布效劳与效劳回调以EAS系统为例。1同UI层Page一样，效劳也不允许抛出任何异常，而是应该以返回错误码(int型，1表示成功，其它值表示失败)形式来说明效劳调用出现了错误，如果方法有返回值，那么返回值以out参数提供。2.如果BAS系统提供了WebServiceRemoting效劳，那么BAS必须提供BAS.Entrance.dll。 BAS.Entrance.
8、dll封装了与BAS效劳交换信息通信机制，客户系统只要通过BAS.Entrance.dll就可以非常简便地访问BAS 提供效劳。3如果BAS需要通过WebServiceRemoting回调客户系统，那么必须提供仅仅定义了接口BAS.CallBack.dll，客户系统将引用该dll，实现其中接口，并将其发布为效劳，供BAS回调。4当WebService参数或返回值需要是复杂类型即架构图中Service Entity，那么Service Entity应该在对应BAS.EntranceParaDef.dll或BAS.CallBackParaDef.dll中定义。 WebService定义方法中复杂类
9、型应该使用Xml字符串代替注意，Entrance和CallBack接口对应效劳方法参数是强类型 ，而Xml字符串和复杂类型对象之间转换应当在BAS.Entrance.dll或BAS.CallBack.dll中实现。用三层架构与设计模式思想部署企业级数据库业务系统开发 1. 三层架构介绍关于架构架构这个词从它出现后,就有许许多多程序员、架构师们剧烈地讨论着它开展，但是架构一词出现，却是随着三层架构出现才出现。当然，目前应用三层架构开发也正是业界最关注主题。那么这里我们来看看单层、双层、三层甚至多层架构到底是怎么一回事。单层构造是80年代以来小型应用构造，在那个构造化编程充满时代，还没有出现架构概
10、念，典型是基于Dbase、Foxbase等小型数据库应用。双层构造同义词可以理解为传统客户/效劳器构造，尽管目前占统治地位构造，但是其封装移植等方面缺陷，已使它步入暮年，典型是基于Oracle、Infomix等大型数据库C/S应用。三层构造是传统客户/效劳器构造开展，代表了企业级应用未来，典型有Web下应用。多层构造和三层构造含义是一样，只是细节有所不同。 之所以会有双层、三层这些提法，是因为应用程序要解决三个层面问题。三层架构概述随着软件工程不断进步和标准以及面向对象编程思想应用，人们对封装、复用、扩展、移置等方面要求，使得双层架构显然更加臃肿繁琐，三层程序架构体系应 运而生，可以说，三层架
11、构体系构造是面向对象思想开展中必然产物。当然三层架构对于目前来说早已经不是什么新鲜事物了,最早听到这个词应该是几年前使用java知道吧， j2ee三层架构体系流行了这么多年，一直没有使用过,不过j2ee三层架构体系提出，对软件系统架构产生了巨大影响，Microsoft、Boland这些公司自然不甘落后，例如平台，更有甚者，称.net之c#为java儿子。那么何谓三层架构？所谓三层架构，是在客户/效劳之间参加了一个中间层，也叫组件层。它与客户层、效劳器层共同构成了三层体系。这里所说三层体系，不是指物理上三层，不是简单地放置三台机器就是三层体系构造，也不仅仅有B/S应用才有三层体系构造，三层是指逻
12、辑上三层。通过引入中间层，将复杂商业逻辑从传统双层构造(Client-Server)应用模型中别离出来，并提供了可伸缩、易于访问、易于管理方法，可以将多种应用效劳分别封装部署于应用效劳器，同时增强了应用程序可用性、平安性、封装复用性、可扩展性和可移置性，使用户在管理上所花费时间最小化，从而实现了便捷、高效、平安、稳定企业级系统应用。分层描述三层架构三层体系应用程序将业务规那么、数据访问、合法性校验等工作放到了中间层进展处理。通常情况下，客户端不直接与数据库进展交互，而是中间层向外提供接口，通过COM/DCOM通讯或者 等方式与中间层建立连接，再经由中间层与数据库进展交互。当然数据通过中间层中转
13、无疑是降低了效率，但是它脱离于界面与数据库完美封装，使得它缺点显然不值得一提。典型三层构造分为表示presentation层, 领域domain层, 以及根底架构infrastructure层，而微软DNA架构定义了三个层：表示层presentation，业务层business，和数据存储层data access，当然J2ee 也有它不同分法不过都大同小异吧。既然我用.net做开发，这大三层我无需多说了,根据我理解，我对此做了更详细分层,界面外观层、界面规那么层、业务接口层、业务逻辑层、实体层、数据访问层、数据存储层共七层，其具体调用如图1所示:图1由图1可以看出，虽然我将系统架构分为七层，实
14、际上大方面来说，它就是一个典型三层架构设计思想。单从这个图来看，数据调用显得繁琐而抽象，也许这时候就会有人说，我只是想实现界面上与用户交互，然后根据用户请求将数据读出/写 入数据库就好了，为什么要做如此复杂分层调用呢？从这个问句中我们也只看到了界面和数据库，也就是说从用户需求来说，就是这两层而已，但是这里我们首 先要搞清楚是三层架构它主要是为程序员为了实现部署、开发、维护企业级数据库系统而效劳。如果我们在中间层实现了对表示层和数据库层完全脱离，其部 署、开发、维护系统费用和时间至少降低到原来一半，甚至更多。部署企业级数据库应用对于一个企业级数据库应用系统上三层架构我是这样部署：系 统通过浏览器
15、或应用程序客户端提供与用户交互平台，并向效劳器提交请求界面外观层；用户提交请求后，界面规那么层对用户数据按照业务逻辑层要求接 口参数封装规那么封装用户数据，然后调用业务接口层对外提供相应命令接口界面规那么层，业务接口层通过对数据进展解析并分别送入不同逻辑处理并向用户 返回处理结果(业务接口层)； 对于数据和命令不同，处理方式也不同，我们将不同处理方式都归类，并将接口层传入数据及命令流入对应处理流程业务规那么层；这时，不同处理流程 分析数据和命令产生出对应一个实体，这个实体根据其本身属性和方法以及上层传入命令，将数据处理为数据访问层需要接口参数，并向数据访问层提交访 问数据库请求，并向业务接口层
16、返回访问结果实体层；数据访问层会将数据转化为数据库可识别语句SQL，并访问数据库层，访问结果会返回给实体层数据访问层；数据库层处理上层传入SQL，读写数据库内置对象，并根据其内置对象本身关系对数据做进一步校验和处理数据库层。这里我所讲到企业级数据库应用系统，不管它是基于B/S应用系统上三层架构设计，还是基于C/S应用系统上三层架构设计，根本上是一样，所不同只是两种方式常用数据传输协议不同，B/S应用系统设计一般数据传递是通过 来完成，C/S应用系统设计那么更多是基于TCP/IP协议来传送数据，当然，随着企业级应用系统对平安性方面要求要求越来越高，更多防火墙架设于物理线路之间，C/S应用系统设计
17、也越来越多地趋向于 ，典型方式如：CLIENTISAPI/CGIServer Database；CLIENTWeb ServiceServer Database；既然提到这两种方式，我简单地提一下它们两者区别及应用，它们不同主要是中间层向客户端提供效劳方式不同，一般情况下这两种方式都需要架设专门用于受理客户端请求Web Server，很明显，它更进一步地表达了三层架构平安性。中间层基于ISAPI/CGI方式可以说正在被Web Service方式所取代，这也正是面向对象思想进一步应用。ISAPI/CGI向客户端提供效劳实际上是远程调用函数，数据一般由程序员自定义构造存储，并基于 与Web Ser
18、ver交互，而Web Service向客户端提供效劳是远程调用类，常常采用XML存储数据，并基于SOAP与Web Server交互。两者优劣势也很明显，前者较XML封装方式，数据量小，传输速度快，后者因为XML臃肿速度上来说是它劣势,不过它平安性以及开发速度占有明显得优势。如果认真看图1中对各层描述，不难看出，里面提到了工厂以及构造器，它是来自于设计模式中一种思想。其中业务逻辑层业务规那么层、实体层就是运用设计模式思想来实现。2. 设计模式思想应用设计模式思想概述设计模式思想引入企业级数据库系统开发，与传统开发模式可谓是一场革命.设计模式之于面向对象设计与开发作用就有如数据构造之于面向过程开发
19、作用一般，其重要性不言而喻。当然学习设计模式过程也是痛苦，对于GoF23种设计模式要一一学懂它，无疑是非常痛苦。面 向对象系统设计与分析实际上就是追求两点：一是高内聚，一是低耦合。这也是我们软件设计所要追求，无论是设计中封装、继承、多态，还是我们 设计模式原那么和实例，都是主要为了追求这两点。有人说，我们系统小，使用设计模式会束缚我们实现，其实不然，就如K_Eckel在他所写设计模式精解一书中提到：设计模式表达是一种思想，而思想是指导行为一切，理解和掌握了设计模式，并不是说记住GoF23种设计模式设计场景以及解决方案，而实际承受是一种软件设计思想熏陶和洗礼，等设计模式思想真正融入到你思想中后，
20、你就会不自觉得去采用设计模式思想去设计你系统，这才是最重要。因此我并不想重复地去讲述这23种设计模式，更不会拘泥于其中任何一种，我只是根据我经历和对设计模式思想理解，来实现我业务逻辑层设计。我们在面向对象设计中常常会遇到一些问题，比方说为了提高程序高内聚低耦合，我们通常会抽象出一些类公共接口以形成抽象基类，这样我们可以为它派生很多个子类,通过申明一个抽象基类但被实例化为指向派生类对象，以到达多态目。然而当业务复杂并产生了大量派生类时，程序员就得记住每一个派生类名字然后New出一个指向它指针。这就给编写程序和维护代码带来了很大困难，这种情况下我们如果要求客户端传入一个名称，我们用一个switch
21、根据传入名称来New一个子类，这就实现了中间层封装。还有比方我一个数据库系统中，有几百个表/视 图等对象，要对它们进展访问，如果只用面向对象思想去操作它们，我们需要把这些数据库对象都抽象为类，封装它们自己属性和方法，这样工作量无疑是非 常巨大。于是我利用设计模式思想动态地分类抽象它们，也就是说，在访问它们之前，才产生具有实体意义类。我们可以将几十个、几百个属性、方法类同 数据库表做成一个Template Class,这样封装方式使得代码量减少到原来几十甚至几百分之一，而且它最大好处是脱离了数据库 等等在面向对象设计中出现问题我们大都可以用设计模式思想去解决它，就如我们在c程序中遇到一些比拟麻烦
22、功能时，就会想到用数据构造中一些算法去解决它一样。数据库应用中设计模式抽象说了这么多，我就举一个例子来说明如何在三层架构部署企业级数据库应用系统中如何使用设计模式：数据库系统中我们最关心就是如何操作数据库中那些对象，我们可以将数据库中对象看作是用来生产某一种产品模具，每一种类型对象就是一种模具,比方表、视图、存储过程，我们可以将它们当作是三种模具，当然你可以根据业务及数据库化分更细一点，比方单表模具，主从表模具，视图模具、存储过程模具、数据库函数模具等等，不够你可以去继续扩展;假使我们现在有一个工厂,它有好多个车间，每个车间只能够使用一种模具来生产产品,我们可以分别给它们起名字叫表车间、视图车
23、间、存储过程车间等。当用户想要往USER表中插入一条记录时候，我们可以说成是在工厂要在表车间使用表模具生产出一个叫做USER产品,然后产品进展加工过程。那生产并加工这个产品过程到底是怎么样呢？这里我说明一下工厂、车间、模具、产品它们各自功能以及在一个产品在产生和加工过程中所处环节，事实上根据它们名字也不难理解。工厂：它要存贮下所有产品名和车间名以及产品名与车间多对一关系，用户需要知道自己要生产产品名字是什么，工厂根据产品名来判断送交给哪个车间去处理.车间：车间使用它拥有模具来产生一个具体产品模具：模具产生一个产品对象产品：进展自加工(插入、删除、修改、查询等)那么，现在我们来看看当用户通过界面
24、层交互，想对表USER插入一条记录过程：事实上用户并不知道它现在操作表叫做USER,而界面层上对象那么必须知道当前操作界面所对应数据库表名字，有了这个条件,界面层调用业务接口层提供获取表信息函数接口【例如：DataSet GetTabInfo(string _tabname;/得到当前表信息】，接口产生一个工厂，工厂就判断这个USER属于哪个车间生产，将USER转交给表车间，表车间产生一个表模具对象，并生产出一个名叫USER产品对象,产品对象调用自己获取信息函数【例如：DataSet GetTabInfo(string _tabname;/得到当前表信息，并记录到产品对象属性中,实际上这个Ge
25、tTabInfo过程调用了数据访问层提供花取字段信息接口】,对本身做了一次加工，也就是说此时USER这个产品已经拥有了USER表信息(字段、主键等),然后返回到业务接口层，业务接口层将这个具体USER产品返回给界面层，界面层得到产品后，将数据填充到产品属性(行和列)中，实际上就是增加一行给字段赋值过程,然后再调用业务接口提供插入数据接口【例如:InsertData(DataSet _tabinfo);】,同样，接口产生工厂，工厂找到车间，重新构造产品，产品对象对本身做插入操作,返回。这就是一个完整操作过程。当我真正地了解了GoF设计模式：可复用面向对象软件根底中思想后，我突然发现真正如K_Ec
26、kel所说，经过了一场软件设计思想洗礼，做系统设计时思想发生了质变化，封装、复用、多态、抽象3.三层架构与设计模式在Web应用系统中应用用c#描述系统架构设计在.net中创立工程1) 首先翻开Microsoft Visual Stdio .Net 2003,新建一个C#工程 Web应用程序，如图2所示:图22) 在新生成解决方案中参加以下类库： GlobalDataTypeLayer:公用参数层 BusinessLayer:业务逻辑层可以将里面四层全局部开，建成类库 DataAccessLayer:数据访问层，为了更好扩展，我在代码表现形式上只将该层从业务逻辑层别离出来界面规那么层可直接置于工
27、程中，因为它是界面外观层基类，在一个命名空间中使用比拟方便。各层之间互相引用联系是这样，首先要将GlobalDataTypeLayer命名空间在其它各层全部引用，UserRoleLayer命名空间中再引用BusinessLayer,BusinessLayer再引用DataAccessLayer。引用事例图如图3所示:图3应用于系统层次构造调用过程以及类代码实现.1界面表示层类图(如图4)图4图2展示是用户界面表示层类图构造，图中显示了共三个类，WebForm Class与PrintControl Class都属于界面外观层。WebForm Class这不仅仅表示一个类，而表示一批类，因为一般情
28、况下与用户交流类属性及操作都大同小异，我们可以从一个基类中派生，以便于编程和管理。当然如果有一些类差异比拟大，可以重新概造相应基类，重新派生，界面层扩展可以很灵活地通过增加基类来实现。PrintControl Class : 打印控制类，主要以客户端脚本来实现，不与效劳器进展数据交互，打印预览之前，打印数据应由WebForm类提交给PrintControl。PageBase Class 这个类属于界面规那么层，它是WebForm基类，事实上界面外观与界面规那么可以放在一个命名空间中，它可以是一个类，也可以是多个类，业务复杂程度也决定了PageBase Class扩展，根据不同需求可以构造相应W
29、ebForm基类来满足业务需求。实现基类局部代码见附录A.2业务逻辑层类图(如图5)图5图5展示了复杂业务逻辑层调用过程,其中主要展示类有六个类，不包含派生子类。ParamData Class 公用参数类，这个类事实上并不属于三层架构中任何层，我单独将其定义为公用参数层，它与三层架构中任何一个类都息息相关,实现代码见附录AInterfaceImpl Class 是业务逻辑层向界面表示层提供接口类，数据由界面规那么层封装传入，对外接口函数根据业务需求可以增加。该类所有函数实现根本都很类似，我这里列出数据库连接和一个SaveData代码实例,见附录AClassBuilderFactory Clas
30、s 工厂类，它作用是根据接口类传入数据找到对应生产构造部件(ClassBuilder),这里很重要是包含了一个简单map，该构造在连接数据库里进展实例化，代码实现见附录AClassBuilder Class 这是构造部件抽象基类，其下可以根据业务需求扩展很多构件器，可以用工厂模式理解其为构件车间，我这里派生构件器有：TableClassBuilder:实体表构件器ViewClassBuilder:视图构件器ProcedureClassBuilder:存储过程构件器OtherClassBuilder:其它构件器基类和实体表构件器代码实现见附录AEntityData Class 这是实体类抽象基类
31、，其下也可以根据业务需求扩展派生实体，前面我提到过我们构件器与实体类是一一对应，一个构件车间只能够生产一类产品。那么对应派生实体就有：TableEntityData:表实体ViewEntityData:视图实体ProcedureEntityData:存储过程实体OtherClassEntityData:其它实体(这个实体自我加工可以灵活定义)实体抽象基类及表实体代码实现见附录ADataAccess Class 是数据访问层数据访问类，这里才真正实现了数据库连接，数据库读写等，将用户数据构造成sql语句与数据库交互。如果想在整个系统中兼容各种数据库，那么可以将它抽象为数据访问抽象基类，可以去派生
32、OracleDataAccess,SqlServerDataAccess,AccessDataAccess等等，它们属性和方法根本上都是一样，只是具体方法中实现有所不同而已，访问Oracle局部实例代码见附录A。在实例化并填充工厂MAP时候用XML存储构件产品名与产品类型名多对一关系，XML构造见附录A。.3 数据库层数据库层指主要是系统采用数据库管理系统(DBMS),在 整套企业级数据库应用系统中，它是最重要一环，其中主要对象有表、视图、存储过程、函数、触发器等，数据许多处理都应该由数据库本身去完成，例如将 复杂查询或者数据写入，都封装为存储过程和函数，将数据写入前后要进展附加操作用触发器实
33、现等等。对于表创立一般应以数据库原理第三范式标准来创 建,允许一定冗余。表及视图创立标准直接影响到代码编写难易度。到 这里，关于三层架构与设计模式思想部署企业级数据库应用系统开发应趋于完整了，我想主要向大家展示实际上就是一种程序设计思想，不管是三层架构还是设 计模式，它们都是软件工程面向对象思想完全表达，目前，我们国家软件业相对来说是很落后，关键问题是软件企业急功近利和程序员思想还停留在构造化 思想上，不能说你在程序中用是类就说你思想是面向对象，也不是说你会使用java编写程序，就说自己懂得面向对象，希望我和大家能一起进步，直正理解面向对象。参 考 文 献1 GoF,设计模式：可复用面向对象软
34、件根底2 k_Eckel,设计模式精解什么是三层架构 所谓三层开发就是将系统整个业务应用划分为表示层业务逻辑层数据访问层，这样有利于系统开发、维护、部署和扩展。分层是为了实现“高内聚、低耦合。采用“分而治之思想，把问题划分开来各个解决，易于控制，易于延展，易于分配资源。 表示层：负责直接跟用户进展交互，一般也就是指系统界面，用于数据录入，数据显示等。意味着只做与外观显示相关工作，不属于他工作不用做。 业务逻辑层：用于做一些有效性验证工作，以更好地保证程序运行强健性。如完成数据添加、修改和查询业务等；不允许指定文本框中输入空字符串，数据格 式是否正确及数据类型验证；用户权限合法性判断等等，通过以
35、上诸多判断以决定是否将操作继续向后传递，尽量保证程序正常运行。 数据访问层：顾名思义，就是用于专门跟数据库进展交互。执行数据添加、删除、修改和显示等。需要强调是，所有数据对象只在这一层被引用，如System.Data.SqlClient等，除数据层之外任何地方都不应该出现这样引用。ASP.NET可以使用.NET平台快速方便地部署三层架构。ASP.NET革命性变化是在网页中也使用基于事件处理，可以指定处理后台代码文件， 可以使用C#、VB、C+和J#作为后台代码语言。. NET中可以方便实现组件装配，后台代码通过命名空间可以方便使用自己定义组件。显示层放在ASPX页面中，数据库操作和逻辑层用组件
36、或封装类来 实现，这样就很方便实现了三层架构。2为什么使用三层架构对于一个简单应用程序来说，代码量不是很多情况下，一层构造或二层构造开发完全够用，没有必要将其复杂化，如果对一个复杂大型系统，设计为一层构造或二层构造开发，那么这样设计存在很严重缺陷。下面会具体介绍，分层开发其实是为大型系统效劳。在开发过程中，初级程序人员出现相似功能经常复制代码，那么同样代码为什么要写那么屡次？不但使程序变得冗长，更不利于维护，一个小小修改或许会涉 及很多页面，经常导致异常产生使程序不能正常运行。最主要面向对象思想没有得到丝毫表达，打着面向对象幌子却依然走着面向过程道路。意识到这样问题，初级程序人员开场将程序中一
37、些公用处理程序写成公共方法，封装在类中，供其它程序调用。例如写一个数据操作类，对数据操作进展合理封 装，在数据库操作过程中，只要类中相应方法数据添加、修改、查询等可以完成特定数据操作，这就是数据访问层，不用每次操作数据库时都写那些重复性 数据库操作代码。在新应用开发中，数据访问层可以直接拿来用。面向对象三大特性之一封装性在这里得到了很好表达。读者现在似乎找到了面向对象 感觉，代码量较以前有了很大减少，而且修改时候也比拟方便，也实现了代码重用性。下面举两个案例，解释一下为什么要使用三层架构。案例一：数据库系统软件由于数据量不断增加，数据库由Access变成了SQL Server数据库，这样原来数
38、据访问层失效了，数据操作对象发生了变化，并且页面中涉及数据对象地方也要进展修改，因为原来可能会使用 OleDbDataReader对象将数据传递给显示页面，现在都得换成SqlDataReader对象，SQL Server和Access支持数据类型也不一致，在显示数据时进展数据转换也要进展修改，这是其中一种情况。案例二：由于特殊情况需要，把Web形式工程改造成Windows应用，此时需要做多少修改呢？如果在Aspx.cs中占据了大量代码，或者还有局部代码存在于Aspx中，那么整个系统是否需要重新来开发呢？ 在上面案例中是否体会到了没有分层开发模式缺陷呢？是否碰到过这样情况呢？这都是由设计不合理造
39、成，多层开发架构出现可以很好地解决该问题，通过程序架构进展合理分层，将极大地提高程序通用性。3使用三层架构开发优点使用三层架构开发有以下优点： 从开发角度和应用角度来看，三层架构比二层架构或单层架构都有更大优势。三层架构适合团队开发，每人可以有不同分工，协同工作使效率倍增。开发二层或 单层应用程序时，每个开发人员都应对系统有较深理解，能力要求很高，开发三层应用程序时，那么可以结合多方面人才，只需少数人对系统全面了解即可，从一 定程度降低了开发难度。 三层架构可以更好支持分布式计算环境。逻辑层应用程序可以在多个计算机上运行，充分利用网络计算功能。分布式计算潜力巨大，远比升级CPU有效。美国人曾利
40、用分式计算解密，几个月就破解了据称永远都破解不了密码。 三层架构最大优点是它平安性。用户只能通过逻辑层来访问数据层，减少了入口点，把很多危险系统功能都屏蔽了。4三层架构种类目前，团队开发人员在开发工程时，大多都使用分层开发架构设计，最常见就是三层架构，目在于使各个层之间只能够被它相邻层产生影响，但是这个 限制常常在使用多层开发时候被违反，这对系统开发是有害。三层架构按驱动模式可划分三种：数据层驱动模式、陈述层驱动模式和隔离驱动模式，其中隔离 驱动模式开发最为重要。下面通过三种模式比照，介绍隔离驱动模式重要性。 数据层驱动模式 所谓数据层驱动模式，就是先设计数据层，陈述层围绕数据层展开，一旦完成
41、了数据层和陈述层，业务层就围绕数据层展开。因为陈述层是围绕数据层展开，这 将会使陈述层中约束不准确，并且限制了业务层变更。由于业务层受到限制，一些简单变化可以通过SQL查询和存储过程来实现。 这种模式非常普遍，它和传统客户效劳端开发相似，并且是围绕已经存在数据库设计。由于陈述层是围绕数据层设计，它常常是凭直觉模仿数据层实际构造。 常常存在一种额外反应循环在陈述层到数据之间，当在设计陈述层不容易实现时候常常会去修改数据层，也就形成了这种反应循环。开发者请求修改数据库方便 陈述层开发，但是对数据层设计却是有害。这种改变是人为而没考虑到其他需求限制。这种修改经常会违反至少损害数据特有规那么，导致不必
42、要数据 冗余和数据非标准化。 陈述层驱动模式 陈述层驱动模式是数据层围绕陈述层展开。业务层完成一般是通过简单SQL查询和很少变化或者隔离。由于数据库设计是为了陈述层方便，并非从数据层设计方面考虑，所以数据库设计在性能上通常很低。陈述层驱动模式设计图如图1.6所示。 隔离驱动模式 用隔离驱动模式设计，陈述层和数据层被独立开发，常常是平行开发。这两层在设计时没有任何相互干扰，所以不会存在人为约束和有害设计元素。当两层 都设计完成后，再设计业务层。业务层责任就是在没有对数据层和陈述层需求变化根底上完成所有转换。陈述层驱动模式设计。 因为现在陈述层和数据层是完全独立，当业务层需求改变时候，陈述层和数据
43、层都可以做相应修改而不影响对方。改变两个在物理上不相邻层不会直接对其 他层产生影响或发生冲突。这就允许数据层构造调整或者陈述层根据用户需求做相应变化，而不需要系统做大调整或者修改。表1.1将对这3种驱动模式 进展比照。表 种驱动模式比照数据层驱动模式陈述层驱动模式隔离驱动模式数据库1很容易设计2产生负面影响3很难改变数据层，因为它和陈述层严密绑定1数据库设计很糟2严重不标准化设计3其他系统不易使用4很难改变数据层，由于它跟陈述层严密绑定1优化设计2集中设计数据库，陈述层对它影响很小业务需求常常不能适应业务需求变化常常适应业务需求变化适应需求变化用户界面是围绕数据层而不是围绕用户，不易修改适合用
44、户扩展界面适合用户扩展界面 扩展性通常可扩张，但是常常在用户界面需要比拟多重写以满足数据库构造，同时数据库可能需要存储一些冗余字段完整性扩张很难，常常只有通过“剪切，粘贴函数来实现很容易扩展综上所述，很容易看出隔离驱动模式优点，隔离驱动模式设计可以极大地提高程序扩展性。在节中应用中就采用了三层架构隔离驱动模式。 三层构造设计与ERP部署规划 金蝶中国 产品经理 尚 弢互联网周刊 随着信息技术飞速开展和企业信息化建立迅猛推进，越来越多企业都在积极选择引进实施ERP来提升自身竞争力。在ERP工程执行过程中，如何 根据企业需求，结合ERP产品应用，在基于企业Intranet和Extranet构成混合
45、网络中有效实施部署ERP产品，是现代企业信息管理责任 部门正面临一项艰巨任务。 必须指出：合理规划部署，不仅仅直接影响到ERP产品各项管理功能有效实现，更直接决定着整个ERP系统运行性能。在对 国内众多ERP实施企业进展调研过程中，我们发现相当多企业ERP系统或多或少都存在着性能瓶颈，这一方面固然和选择产品本身性能有关，另一方面也 与企业对ERP产品部署规划缺乏应有了解和重视有重要关系。 复杂应用系统解决之道-三层构造设计 业界当前比拟成熟解决方案是三层构造设计，例如基于微软体系架构金蝶K/3 ERP系统就是使用典型Windows DNA三层体系构造。它具有数据访问平安性增强事物对象管理高可用
46、性强大可扩展性等突出特点。 特别是在可扩展性方面，K/3 ERP三层体系构造表达了业界倡导自由扩展方案技术精华，它可以允许用户针对不同业务复杂状况对K/3系统运算负荷能力需求而在方案中做灵活扩展处理。 从上图我们可以看到，三层构造设计中，ERP产品可以划分为至少三个逻辑层：Presentation表示层、Business Logic业务逻辑层、Data数据层。表示层就是我们通常讲客户端，它可以是32位Windows界面客户端，也可以是基于浏览器瘦客户 端；数据层就是对应于专业数据库效劳，例如：Oracle/DB2/SQL Server等；业务逻辑层那么集中表达了ERP厂商产品功能，通常又被称为
47、中间层。 表示效劳层负责： 从用户收集信息 将用户信息发送到业务效劳层做处理 从业务效劳层接收处理结果 将结果显示给用户 业务效劳层负责： 从表示层接收输入 与数据层交互执行已设计业务 操作业务逻辑，系统效劳等 将处理结果发送到表示层。 数据效劳层负责： 数据存储 数据获取 数据维护 数据完整性 基于三层构造ERP部署规划设计 我们看到，三层构造下ERP规划，从本质上讲就是如何对客户端主机、业务逻辑层效劳器、数据库效劳器进展规划部署过程。企业需求 并不是一成不变，一方面，企业伴随着成长开展，需求一定会发生增长；另一方面，成熟企业ERP通常会选择“整体规划，分步实施“开展策略。因此负责 ERP软件厂商应该并且能够预见到企业需求扩展同时在部署方案设计上予以表达和支持。 下面我们就从一个企业模拟案例出发，