不改变网站怎么做关键词优化,广东南方通信建设有限公司官方网站,温州手机网站制作公司电话,天津怎样做网站推广1. 三层架构介绍 1.1关于架构 架构这个词从它的出现后,就有许许多多的程序员、架构师们激烈地讨论着它的发展#xff0c;但是架构一词的出现#xff0c;却是随着三层架构的出现才出现的。当然#xff0c;目前应用三层架构开发也正是业界最关注的主题。那么这里我们来看看单层… 1. 三层架构介绍 1.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àWeb Serviceà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,而界面层上的对象则必须知道当前操作界面所对应数据库表的名字有了这个已知条件,界面层调用业务接口层的提供的获取表信息函数接口【例如DataSet GetTabInfo(string _tabname;//得到当前表的信息】接口产生一个工厂工厂就判断这个USER属于哪个车间生产将USER转交给表车间表车间产生一个表模具对象并生产出一个名叫USER的产品对象,产品对象调用自己的获取信息函数【例如DataSet GetTabInfo(string _tabname;//得到当前表的信息并记录到产品对象属性中,实际上这个GetTabInfo过程调用了数据访问层提供的花取字段信息接口】,对本身做了一次加工也就是说此时USER这个产品已经拥有了USER表的信息(字段、主键等),然后返回到业务接口层业务接口层将这个具体的USER产品返回给界面层界面层得到产品后将数据填充到产品的属性(行和列)中实际上就是增加一行给字段赋值的过程,然后再调用业务接口提供的插入数据接口【例如:InsertData(DataSet _tabinfo);】,同样的接口产生工厂工厂找到车间重新构造产品产品对象对本身做插入操作,返回。这就是一个完整的操作过程。 当我真正地了解了GoF的《设计模式可复用面向对象软件的基础》中的思想后我突然发现真正如K_Eckel所说经过了一场软件设计思想的洗礼做系统设计时的思想发生了质的变化封装、复用、多态、抽象…… 3.三层架构与设计模式在Web应用系统中的应用 3.1用c#描述系统架构设计 3.1.1在.net中创建工程 1) 首先打开Microsoft Visual Stdio .Net 2003,新建一个C#项目asp.net Web应用程序如图2所示: 图2 2) 在新生成的解决方案中加入以下类库 GlobalDataTypeLayer:公用参数层 BusinessLayer:业务逻辑层可以将里面的四层全部分开建成类库 DataAccessLayer:数据访问层为了更好的扩展我在代码表现形式上只将该层从业务逻辑层分离出来 界面规则层可直接置于asp.net项目中因为它是界面外观层的基类在一个命名空间中使用比较方便。各层之间互相的引用联系是这样的首先要将GlobalDataTypeLayer命名空间在其它各层全部引用UserRoleLayer命名空间中再引用BusinessLayer,BusinessLayer再引用DataAccessLayer。引用事例图如图3所示: 图3 3.1.2应用于系统层次结构调用过程以及类的代码实现 3.1.2.1界面表示层类图(如图4) 图4 图2展示的是用户界面表示层的类图结构图中显示了共三个类WebForm Class与PrintControl Class都属于界面外观层。 WebForm Class这不仅仅表示一个类而表示一批类因为一般情况下与用户交流的类的属性及操作都大同小异我们可以从一个基类中派生以便于编程和管理。当然如果有一些类差别比较大可以重新概造相应的基类重新派生界面层的扩展可以很灵活地通过增加基类来实现。 PrintControl Class : 打印控制类主要以客户端脚本来实现不与服务器进行数据交互打印预览之前打印数据应由WebForm类提交给PrintControl。 PageBase Class 这个类属于界面规则层它是WebForm的基类事实上界面外观与界面规则可以放在一个命名空间中它可以是一个类也可以是多个类业务的复杂程度也决定了PageBase Class的扩展根据不同的需求可以构造相应的WebForm基类来满足业务需求。实现基类部分代码见附录A. 3.1.2.2业务逻辑层类图(如图5) 图5 图5展示了复杂的业务逻辑层调用过程,其中主要展示的类有六个类不包含派生的子类。 ParamData Class 公用参数类这个类事实上并不属于三层架构中的任何层我单独将其定义为公用参数层它与三层架构中的任何一个类都息息相关,实现代码见附录A InterfaceImpl Class 是业务逻辑层向界面表示层提供的接口类数据由界面规则层封装传入对外接口函数根据业务需求可以增加。该类的所有函数实现基本都很类似我这里列出数据库连接和一个SaveData的代码实例,见附录A ClassBuilderFactory Class 工厂类它的作用是根据接口类传入的数据找到对应的生产构造部件(ClassBuilder),这里很重要的是包含了一个简单的map该结构在连接数据库里进行实例化代码实现见附录A ClassBuilder Class 这是构造部件的抽象基类其下可以根据业务的需求扩展很多的构件器可以用工厂的模式理解其为构件车间我这里派生的构件器有 TableClassBuilder:实体表构件器 ViewClassBuilder:视图构件器 ProcedureClassBuilder:存储过程构件器 OtherClassBuilder:其它构件器 基类和实体表构件器的代码实现见附录A EntityData Class 这是实体类的抽象基类其下也可以根据业务的需求扩展派生实体前面我提到过我们的构件器与实体类是一一对应的一个构件车间只能够生产一类产品。那么对应的派生实体就有 TableEntityData:表实体 ViewEntityData:视图实体 ProcedureEntityData:存储过程实体 OtherClassEntityData:其它实体(这个实体的自我加工可以灵活定义) 实体抽象基类及表实体的代码实现见附录A DataAccess Class 是数据访问层的数据访问类这里才真正实现了数据库连接数据库读写等将用户的数据构造成sql语句与数据库交互。如果想在整个系统中兼容各种数据库那么可以将它抽象为数据访问的抽象基类可以去派生OracleDataAccess,SqlServerDataAccess,AccessDataAccess等等它们的属性和方法基本上都是相同的只是具体方法中的实现有所不同而已访问Oracle部分实例代码见附录A。 在实例化并填充工厂MAP的时候用XML存储构件的产品名与产品类型名的多对一关系XML结构见附录A。 3.1.2.3 数据库层 数据库层指的主要是系统采用的数据库管理系统(DBMS),在 整套企业级数据库应用系统中它是最重要的一环其中主要的对象有表、视图、存储过程、函数、触发器等数据的许多处理都应该由数据库本身去完成例如将 复杂的查询或者数据写入都封装为存储过程和函数将数据写入前后要进行的附加操作用触发器实现等等。对于表的创建一般应以数据库原理的第三范式规范来创 建,允许一定的冗余。表及视图的创建规范直接影响到代码编写的难易度。 到 这里关于三层架构与设计模式思想部署企业级数据库应用系统开发应趋于完整了我想主要向大家展示的实际上就是一种程序设计的思想不管是三层架构还是设 计模式它们都是软件工程面向对象思想的完全体现目前我们国家软件业相对来说是很落后的关键的问题是软件企业的急功近利和程序员思想还停留在结构化 思想上不能说你在程序中用的是类就说你的思想是面向对象也不是说你会使用java编写程序就说自己懂得面向对象希望我和大家能一起进步直正理解面向对象。 转载于:https://www.cnblogs.com/andyWqh520/p/3828798.html
