C#三层架构详解

1、 三层架构将数据层、应用层和业务层分离，业务层通过应用层访问数据库，保护数据安 全，利于负载平衡，提高运行效率，方便构建不同网络环境下的分布式应用； 业务层主要作用是接收用户的指令或者数据输入，提交给应用层做处理，同时负责将 业务逻辑层的处理结果显示给用户。相比传统的应用方式，业务层对硬件的资源要求较 低； 应用层依据应用规模的不同，所承受的负荷会有较大的差异，另外客户端的数目，应 用的复杂程度都会对其造成一定的影响。 ERP三层结构提供了非常好的可扩张性，可以将逻辑服务分布到多台服务器来处理，从 而提供了良好的伸缩方案； 数据层包括存储数据的数据库服务器和处理数据和缓存数据的组件。组件将大量

2、使用 的数据放入系统的缓存库，以提高数据访问和处理的效率 同时ERP用大型数据库提供高性能、可靠性高的海量数据存储能力存储 ERP的业务数 据。 三层架构(3-tier application)通常意义上的三层架构就是将整个业务应用划分为： 表现层 (UI)、业务逻辑层(BLD、数据访问层(DAL)。区分层次的目的即为了 “高内聚， 低耦合”的思想。 概念简介 1、 表现层 （UI）:通俗讲就是展现给用户的界面，即用户在使用一个系统 的时候他的所见所得。 2、 业务逻辑层（BLL）:针对具体问题的操作，也可以说是对数据层的操 作，对数据业务逻辑处理。 3、 数据访问层（DAL）:该层所做事务直

3、接操作数据库，针对数据的增添、 删除、修改、更新、查找等。 概述 在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微 软推荐的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层 （又或成为领域层）、表示层。 三层结构原理： 3个层次中，系统主要功能和业务逻辑都在业务逻辑层进行处理。 所谓三层体系结构， 是在客户端与数据库之间加入了一个 中间层”，也叫组件 层。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是 三层体系结构， 也不仅仅有 B/S应用才是三层体系结构， 三层是指逻辑上的三层， 即使这三个层放置到一台机器上。 三层体系的应用程序将业务规则

4、、数据访问、合法性校验等工作放到了中间 层进行处理。通常情况下，客户端不直接与数据库进行交互，而是通过 COM/DC OM通讯与中间层建立连接，再经由中间层与数据库进行交互。 表小层 位于最外层（最上层），离用户最近。用于显示数据和接收用户输入的数 据，为用户提供一种交互式操作的界面 业务逻辑层 业务逻辑层(Business Logic Layer )无疑是系统架构中体现核心价值的 部分。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有 关的系统设计，也即是说它是与系统所应对的领域( Domain )逻辑有关，很多时 候，也将业务逻辑层称为领域层。例如 Martin Fowle

5、r在Patterns of Enterpri se Application Architecture 一书中，将整个架构分为三个主要的层：表示层、 领域层和数据源层。作为领域驱动设计的先驱 Eric Evans ,对业务逻辑层作了更 细致地划分，细分为应用层与领域层，通过分层进一步将领域逻辑与领域逻辑的 解决方案分离。 业务逻辑层在体系架构中的位置很关键，它处于数据访问层与表示层中间， 起到了数据交换中承上启下的作用。由于层是一种弱耦合结构，层与层之间的依 赖是向下的，底层对于上层而言是 无知”的，改变上层的设计对于其调用的底层而 言没有任何影响。如果在分层设计时，遵循了面向接口设计的思想，那

6、么这种向 下的依赖也应该是一种弱依赖关系。因而在不改变接口定义的前提下，理想的分 层式架构，应该是一个支持可抽取、可替换的 抽屉”式架构。正因为如此，业务逻 辑层的设计对于一个支持可扩展的架构尤为关键， 因为它扮演了两个不同的角色。 对于数据访问层而言，它是调用者；对于表示层而言，它却是被调用者。依赖与 被依赖的关系都纠结在业务逻辑层上，如何实现依赖关系的解耦，则是除了实现 业务逻辑之外留给设计师的任务。 数据层 数据访问层：有时候也称为是持久层，其功能主要是负责数据库的访问， 可以访问数据库系统、二进制文件、文本文档或是 XML文档。 简单的说法就是实现对数据表的 Select , Inse

7、rt , Update , Delete的操作。 如果要加入 ORM的元素，那么就会包括对象和数据表之间的 mapping ,以及对 象实体的持久化。 优缺点 优点 1、 开发人员可以只关注整个结构中的其中某一层； 2、 可以很容易的用新的实现来替换原有层次的实现； 3、可以降低层与层之间的依赖; 4、 有利于标准化； 5、 利于各层逻辑的复用。 缺点 1、 降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务 可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。 2、 有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表 示层中需要增加一个功能，为保证

8、其设计符合分层式结构，可能需要在相应的业 务逻辑层和数据访问层中都增加相应的代码。 规则 三层结构的程序不是说把项目分成 DAL, BLL, WebUI三个模块就叫三层了 ， 下面几个问题在你的项目里面： 1. UILayer里面只有少量(或者没有)的SQL语句或者存储过程调用，并且这 些语句保证不会修改数据 ？ 2. 如果把UILayer拿掉,你的项目还能在 Interface/API的层次上提供所有功 能吗？ 3. 你的DAL可以移植到其他类似环境的项目吗 ？ 4. 三个模块,可以分别运行于不同的服务器吗 ？ 如果不是所有答案都为 YES,那么你的项目还不能算是严格意义上的三层程 序.三层

9、程序有一些需要约定遵守的规则： 1. 最关键的，UI层只能作为一个外壳 ，不能包含任何 BizLogic的处理过程 2. 设计时应该从 BLL出发，而不是UI出发.BLL层在API上应该实现所有 B izLogic, 以面向对象的方式 3. 不管数据层是一个简单的 SqlHelper也好，还是带有Mapping过的Class es也好，应该在一定的抽象程度上做到系统无关 4. 不管使用 COM+(Enterprise Service),还是 Remoting,还是 WebService 之类的远程对象技术，不管部署的时候是不是真的分别部署到不同的服务器上 ， 最起码在设计的时候要做这样的考虑

10、，更远的，还得考虑多台服务器通过负载均 衡作集群 所以考虑一个项目是不是应该应用三层 /多层设计时，先得考虑下是不是真的 需要？实际上大部分程序就开个 WebApplication 就足够了 ,完全没必要作的这么 复杂.而多层结构，是用于解决真正复杂的项目需求的。 与MVC的区别 MVC （模型 Model-视图View-控制器Controller ）是一种设计模式，我们可 以用它来创建在域对象和 UI表示层对象之间的区分。 同样是架构级别的，相同的地方在于他们都有一个表现层，但是他们不同的 地方在于其他的两个层。 在三层架构中没有定义 Controller的概念。这是我认为最不同的地方。 而

11、MVC 也没有把业务的逻辑访问看成两个层， 这是采用三层架构或 MVC搭建程序最主要 的区别。当然了。在三层中也提到了 Model ,但是三层架构中 Model的概念与 MVC中Model的概念是不一样的， 兰层”中典型的 Model层是以实体类构成的， 而MVC里，则是由业务逻辑与访问数据组成的。 三层结构的优点 分层式结构究竟其优势何在？ Martin Fowler 在Patterns of Enterprise Application Architecture 一书中给出了答案： 1、 开发人员可以只关注整个结构中的其中某一层； 2、 可以很容易的用新的实现来替换原有层次的实现； 3、

12、可以降低层与层之间的依赖； 4、 有利于标准化； 5、 利于各层逻辑的复用。 概括来说，分层式设计可以达至如下目的：分散关注、松散耦合、逻辑复用、标准 定义。 一个好的分层式结构， 可以使得开发人员的分工更加明确。 一旦定义好各层次之间 的接口，负责不同逻辑设计的开发人员就可以分散关注，齐头并进。例如 UI人员只需 考虑用户界面的体验与操作， 领域的设计人员可以仅关注业务逻辑的设计， 而数据库设 计人员也不必为繁琐的用户交互而头疼了。每个开发人员的任务得到了确认，开发进度 就可以迅速的提高。 松散耦合的好处是显而易见的。 如果一个系统没有分层， 那么各自的逻辑都紧紧纠 缠在一起，彼此间相互依赖

13、，谁都是不可替换的。一旦发生改变，则牵一发而动全身， 对项目的影响极为严重。降低层与层间的依赖性，既可以良好地保证未来的可扩展，在 复用性上也是优势明显。每个功能模块一旦定义好统一的接口， 就可以被各个模块所调 用，而不用为相同的功能进行重复地开发。 进行好的分层式结构设计，标准也是必不可少的。只有在一定程度的标准化基础上， 这个系统才是可扩展的，可替换的。而层与层之间的通信也必然保证了接口的标准化。 如果是一个考试系统， 考试合格的最低分数线要改， 只需要修改业务逻辑相对应函 数就可以了，只要此函数的入口参数和返回内容不变，在客户端不需作任何改动。在这 里，看到了面向对象编程的特性之一封装性

14、的优点，而这一点在开发大型应用时尤其有 用，可以把开发人员分成两组，一组负责开发界面层，另一组负责开发商业逻辑层，双 方只要按照事先商定的函数接口，并行地开发就可以，而不必向从前那样，后面的工作 必须等前面的工作完成后才能开始。当然，这样的开发模式需要很好的项目协调和文档 作支持。 如果现在用的系统是 SQL SERVE散据库，由于各种原因要更改用 ORACLE如果不 是三层结构系统的话，可能需要改很多代码，延长了开发周期。现在使用了三层结构， 只要在加一个Oracle的数据访问层。这样就可以实现多数据库了。 现在可能要做另外一个系统了，该系统也要对数据库进行操作。如果以前编写过， 这样的一个

15、数据层。只要把以前写的那个数据层拷贝过来就可以了。实现代码复用。从 而减短了软件的开发周期了。 三层结构的缺点 “金无足赤，人无完人”，分层式结构也不可避免具有一些缺陷： 1、 降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以 直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。 2、 有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层 中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和 数据访问层中都增加相应的代码。 基于组件的三层B/S结构概述 在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微软推

16、荐 的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又或成为领 域层）、表示层。 三层结构原理 3个层次中，系统主要功能和业务逻辑都在业务逻辑层进行处理 所谓三层体系结构，是在客户端与数据库之间加入了一个“中间层”，也叫组件层。 这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结 构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放 置到一台机器上。 三层体系的应用程序将业务规则、 数据访问、合法性校验等工作放到了中间层进行 处理。通常情况下，客户端不直接与数据库进行交互，而是通过 COM/DCOM通讯与中 间层建立连接，再

17、经由中间层与数据库进行交互。 表示层 位于最外层（最上层），离用户最近。用于显示数据和接收用户输入的数据，为用 户提供一种交互式操作的界面 业务逻辑层 业务逻辑层（Business Logic Layer无疑是系统架构中体现核心价值的部分。它的 关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计，也 即是说它是与系统所应对的领域（Domain）逻辑有关，很多时候，也将业务逻辑层称为 领域层。例如 Martin Fowler 在Patterns of Enterprise Application Architecture一书中， 将整个架构分为三个主要的层：表示层、领域层和

18、数据源层。作为领域驱动设计的先驱 Eric Evans对业务逻辑层作了更细致地划分，细分为应用层与领域层，通过分层进一步 将领域逻辑与领域逻辑的解决方案分离。 业务逻辑层在体系架构中的位置很关键， 它处于数据访问层与表示层中间， 起到了 数据交换中承上启下的作用。由于层是一种弱耦合结构，层与层之间的依赖是向下的， 底层对于上层而言是“无知”的，改变上层的设计对于其调用的底层而言没有任何影响。 如果在分层设计时，遵循了面向接口设计的思想，那么这种向下的依赖也应该是一种弱 依赖关系。因而在不改变接口定义的前提下，理想的分层式架构，应该是一个支持可抽 取、可替换的“抽屉”式架构。正因为如此，业务逻辑

19、层的设计对于一个支持可扩展的 架构尤为关键，因为它扮演了两个不同的角色。对于数据访问层而言，它是调用者；对 于表示层而言，它却是被调用者。依赖与被依赖的关系都纠结在业务逻辑层上，如何实 现依赖关系的解耦，则是除了实现业务逻辑之外留给设计师的任务。 数据层 数据访问层：有时候也称为是持久层，其功能主要是负责数据库的访问，可以访问 数据库系统、二进制文件、文本文档或是 XML文档。 简单的说法就是实现对数据表的 Select, Insert, Update, Delete的操作。如果要加 入ORM的元素，那么就会包括对象和数据表之间的 mapping ,以及对象实体的持久化。 MVC与三层架构的异

20、同点 同样是架构级别的，它们有什么相同点和不同点呢？这篇文章讨论一下它们的异同 点。希望能帮助读者理解其中的玄机。 ：） 其实它们相同的地方在于他们都有一个表现层。 但是他们不同的地方在于其他的两个层。 首先先解释一下 MVC。V即View.是视图的意思。C即Controler.是控制器的意思 而M即Model，是模型的意思。这三个里.最不容易理解的应该是 Model.就是什么是 Model，而为什么叫 Model。我先不说为什么叫 Model，先解释 Controler。 Controller是控制器的意思，所谓控制器，就是将用户请求转发给模型层，经过处 理后把结果返回到界面展现的一个中间层，那么 Controler到底管什么工作呢？先不说. 先来看下在Java Web中这三个层一般的定义，一般