c#三层架构

c#三层架构.txt第一次笑是因为遇见你，第一次哭是因为你不在，第一次笑着流泪是因为不能拥有你。一．三层架构图2006052029123456三层架构图三层架构图三层架构图二．系统各层次职责1.UI（UserInterface）层的职责是数据的展现和采集，数据采集的结果通常以Entityobject提交给BL层处理。2.ServiceInterface侧层用于将业务或数据资源发布为服务（如WebServices）。2.BL（BusinessLogic）层的职责是按预定的业务逻辑处理UI层提交的请求。（1）BusinessFunction子层负责基本业务功能的实现。（2）BusinessFlow子层负责将BusinessFunction子层提供的多个基本业务功能组织成一个完整的业务流。3.（Transaction只能在BusinessFlow子层开启。）3．ResourceAccess层的职责是提供全面的资源访问功能支持，并向上层屏蔽资源的来源。（1）BEM（BusinessEntityManager）子层采用DataAccess子层和ServiceAccess子层来提供业务需要的基础数据/资源访问能力。（2）DataAccess子层负责从数据库中存取资源，并向BEM子层屏蔽所有的SQL语句以及数据库类型差异。DBAdapter子层负责屏蔽数据库类型的差异。ORM子层负责提供对象－关系映射的功能。Relation子层提供ORM无法完成的基于关系（Relation）的数据访问功能。（3）ServiceAccess子层用于以SOA的方式从外部系统获取资源。注：ServiceEntrance用于简化对Service的访问，它相当于Service的代理，客户直接使用ServiceEntrance就可以访问系统发布的服务。ServiceEntrance为特定的平台（如Java、.Net）提供强类型的接口，内部可能隐藏了复杂的参数类型转换。（4）ConfigAccess子层用于从配置文件中获取配置object或将配置object保存倒配置文件。4．Entity侧层跨越UI/BEM/ResourceManager层，在这些层之间传递数据。Entity侧层中包含三类Entity，如下图所示：三．AspectAspect贯穿于系统各层，是系统的横切关注点。通常采用AOP技术来对横切关注点进行建模和实现。1．SecurtiyAspect：用于对整个系统的Security提供支持。2．ErrorHandlingAspect：整个系统采用一致的错误/异常处理方式。3．LogAspect：用于系统异常、日志记录、业务操作记录等。四．规则1．系统各层次及层内部子层次之间都不得跨层调用。2．Entityobject在各个层之间传递数据。3．需要在UI层绑定到列表的数据采用基于关系的DataSet传递，除此之外，应该使用Entityobject传递数据。4．对于每一个数据库表（Table）都有一个DBEntityclass与之对应，针对每一个Entityclass都会有一个BEMClass与之对应。5．有些跨数据库或跨表的操作（如复杂的联合查询）也需要由相应的BEMClass来提供支持。6．对于相对简单的系统，可以考虑将BusinessFunction子层和BusinessFlow子层合并为一个。7．UI层和BL层禁止出现任何SQL语句。//???五．错误与异常异常可以分为系统异常（如网络突然断开）和业务异常（如用户的输入值超出最大范围），业务异常必须被转化为业务执行的结果。1．DataAccess层不得向上层隐藏任何异常（该层抛出的异常几乎都是系统异常）。2．要明确区分业务执行的结果和系统异常。比如验证用户的合法性，如果对应的用户ID不存在，不应该抛出异常，而是返回（或通过out参数）一个表示验证结果的枚举值，这属于业务执行的结果。但是，如果在从数据库中提取用户信息时，数据库连接突然断开，则应该抛出系统异常。3．在有些情况下，BL层应根据业务的需要捕获某些系统异常，并将其转化为业务执行的结果。比如，某个业务要求试探指定的数据库是否可连接，这时BL就需要将数据库连接失败的系统异常转换为业务执行的结果。4．UI层(包括Service层)除了从调用BL层的API获取的返回值来查看业务的执行结果外，4.还需要截获所有的系统异常，并将其解释为友好的错误信息呈现给用户。六．项目组织目结构以BAS系统为例。//制动辅助系统1．主目录结构：2．命名空间命名：每个dll的根命名空间即是该dll的名字，如EAS.BL.dll的根命名空间就是EAS.BL。每个根命名空间下面可以根据需求的分类而增加子命名空间，比如，EAS.BL的子空间EAS.BL.Order与EAS.BL.Permission分别处理不同的业务逻辑。3.包含众多子项目的庞大项目的物理组织：核心子项目Core的位置：Core子项目中包含一些公共的基础设施，如错误处理、权限控制方面等。七．发布服务与服务回调以EAS系统为例。1．同UI层的Page一样，服务也不允许抛出任何异常，而是应该以返回错误码(int型，1表示成功，其它值表示失败)的形式来表明服务调用出现了错误，如果方法有返回值，则返回值以out参数提供。2.如果BAS系统提供了WebService（Remoting）服务，则BAS必须提供BAS.Entrance.dll。BAS.Entrance.dll封装了与BAS服务交换信息的通信机制，客户系统只要通过BAS.Entrance.dll就可以非常简便地访问BAS提供的服务。3．如果BAS需要通过WebService（Remoting）回调客户系统，则必须提供仅仅定义了接口的BAS.CallBack.dll，客户系统将引用该dll，实现其中的接口，并将其发布为服务，供BAS回调。4．当WebService的参数或返回值需要是复杂类型――即架构图中的ServiceEntity，则ServiceEntity应该在对应的BAS.EntranceParaDef.dll或BAS.CallBackParaDef.dll中定义。WebService定义的方法中的复杂类型应该使用Xml字符串代替（注意，Entrance和CallBack接口对应服务的方法的参数是强类型的），而Xml字符串和复杂类型对象之间的转换应当在BAS.Entrance.dll或BAS.CallBack.dll中实现。用三层架构与设计模式思想部署企业级数据库业务系统开发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），和数据存储层（dataaccess），当然J2ee也有它不同的分法不过都大同小异吧。既然我用.net做的开发，这大三层我无需多说了,根据我的理解，我对此做了更详细的分层,界面外观层、界面规则层、业务接口层、业务逻辑层、实体层、数据访问层、数据存储层共七层，其具体的调用如图1所示:图1由图1可以看出，虽然我将系统的架构分为七层，实际上大的方面来说，它就是一个典型的三层架构设计思想。单从这个图来看，数据的调用显得繁琐而抽象，也许这时候就会有人说，我只是想实现界面上与用户交互，然后根据用户的请求将数据读出/写入数据库就好了，为什么要做如此复杂的分层调用呢？从这个问句中我们也只看到了界面和数据库，也就是说从用户的需求来说，就是这两层而已，但是这里我们首先要搞清楚的是三层架构它主要是为程序员为了实现部署、开发、维护企业级数据库系统而服务的。如果我们在中间层实现了对表示层和数据库层的完全脱离，其部署、开发、维护系统的费用和时间至少降低到原来的一半，甚至更多。1.4部署企业级数据库应用对于一个企业级数据库应用系统上的三层架构我是这样部署的：系统通过浏览器或应用程序客户端提供与用户的交互平台，并向服务器提交请求（界面外观层）；用户提交请求后，界面规则层对用户的数据按照业务逻辑层要求的接口参数封装规则封装用户数据，然后调用业务接口层对外提供的相应命令接口（界面规则层），业务接口层通过对数据进行解析并分别送入不同的逻辑处理并向用户返回处理结果(业务接口层)；对于数据和命令的不同，处理方式也不同，我们将不同的处理方式都归类，并将接口层传入的数据及命令流入对应处理流程（业务规则层）；这时，不同的处理流程分析数据和命令产生出对应的一个实体，这个实体根据其本身的属性和方法以及上层传入的命令，将数据处理为数据访问层需要的接口参数，并向数据访问层提交访问数据库的请求，并向业务接口层返回访问结果（实体层）；数据访问层会将数据转化为数据库可识别的语句（SQL），并访问数据库层，访问结果会返回给实体层（数据访问层）；数据库层处理上层传入的SQL，读写数据库内置对象，并根据其内置对象本身的关系对数据做进一步校验和处理（数据库层）。这里我所讲到的企业级数据库应用系统，不论它是基于B/S应用系统上的三层架构设计，还是基于C/S应用系统上的三层架构设计，基本上是一样的，所不同的只是两种方式常用的数据传输