全然看不懂

基于软件三层架构的研究报告

引言

三层结构是传统的客户/server结构的发展，代表了企业级应用的未来，典型的有Web下的应用。多层结构和三层结构的含义是一样的，仅仅是细节有所不同。之所以会有双层、三层这些提法，是由于应用程序要解决三个层面的问题。

3、数据訪问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、改动、查找等。

（二）三层结构原理： 　　

3个层次中，系统主要功能和业务逻辑都在业务逻辑层进行处理。 　　

所谓三层体系结构，是在client与数据库之间增加了一个“中间层”，也叫组件层。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不唯独B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。三层体系的应用程序将业务规则、数据訪问、合法性校验等工作放到了中间层进行处理。通常情况下，client不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，再经由中间层与数据库进行交互。

（三）各层的作用

数据訪问层：

有时候也称为是持久层，其功能主要是负责数据库的訪问，能够訪问数据库系统、二进制文件、文本文档或是XML文档。简单的说法就是实现对数据表的Select，Insert，Update，Delete的操作。假设要增加ORM的元素，那么就会包含对象和数据表之间的mapping，以及对象实体的持久化。主要是对原始数据（数据库或者文本文件等存放数据的形式）的操作层，而不是指原始数据，也就是说，是对数据的操作，而不是数据库,详细为业务逻辑层或表示层提供数据服务。

业务逻辑层：

主要是针对详细的问题的操作，也能够理解成对数据层的操作,对数据业务逻辑处理，假设说数据层是积木，那逻辑层就是对这些积木的搭建。业务逻辑层（Business Logic Layer）无疑是系统架构中体现核心价值的部分。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计，也即是说它是与系统所应对的领域（Domain）逻辑有关，非常多时候，也将业务逻辑层称为领域层。比如Martin Fowler在《Patternsof Enterprise Application Architecture》一书中，将整个架构分为三个基本的层：表示层、领域层和数据源层。作为领域驱动设计的先驱Eric Evans，对业务逻辑层作了更仔细地划分，细分为应用层与领域层，通过分层进一步将领域逻辑与领域逻辑的解决方式分离。 　　业务逻辑层在体系架构中的位置非常关键，它处于数据訪问层与表示层中间，起到了数据交换中承上启下的作用。由于层是一种弱耦合结构，层与层之间的依赖是向下的，底层对于上层而言是“无知”的，改变上层的设计对于其调用的底层而言没有不论什么影响。假设在分层设计时，遵循了面向接口设计的思想，那么这样的向下的依赖也应该是一种弱依赖关系。因而在不改变接口定义的前提下，理想的分层式架构，应该是一个支持可抽取、可替换的“抽屉”式架构。正由于如此，业务逻辑层的设计对于一个支持可扩展的架构尤为关键，由于它扮演了两个不同的角色。对于数据訪问层而言，它是调用者；对于表示层而言，它却是被调用者。依赖与被依赖的关系都纠结在业务逻辑层上，怎样实现依赖关系的解耦，则是除了实现业务逻辑之外留给设计师的任务。 　　

表示层：

位于最外层（最上层），离用户近期。用于显示数据和接收用户输入的数据，为用户提供一种交互式操作的界面。主要表示WEB方式,也能够表示成WINFORM方式,WEB方式也能够表现成:aspx, 假设逻辑层相当强大和完好,不管表现层怎样定义和更改,逻辑层都能完好地提供服务。

（四）详细调用

微软的DNA架构定义了三个层：表示层（presentation），业务逻辑层（business），和数据訪问层（data access）。详细又分为：界面外观层、界面规则层、业务接口层、业务逻辑层、实体层、数据訪问层、数据存储层共七层，其详细的调用如图1所看到的:

（五）规则

    1．系统各层次及层内部子层次之间都不得跨层调用。
    2．Entityobject 在各个层之间传递数据。
    3．须要在UI层绑定到列表的数据採用基于关系的DataSet传递，除此之外，应该使用Entityobject传递数据。
    4．对于每个数据库表（Table）都有一个DB Entity class与之相应，针对每个Entityclass都会有一个BEM Class与之相应。
    5．有些跨数据库或跨表的操作（如复杂的联合查询）也须要由对应的BEM Class来提供支持。
    6．对于相对简单的系统，能够考虑将Business Function子层和Business Flow 子层合并为一个。
    7．UI层和BL层禁止出现不论什么SQL语句。

2、能够非常easy的用新的实现来替换原有层次的实现；　　

3、能够减少层与层之间的依赖； 　　

4、有利于标准化； 　　

5、利于各层逻辑的复用。

（二）缺点

1、减少了系统的性能。这是不言而喻的。假设不採用分层式结构，非常多业务能够直接造訪数据库，以此获取对应的数据，现在却必须通过中间层来完毕。 　　

2、有时会导致级联的改动。这样的改动尤其体如今自上而下的方向。假设在表示层中须要添加一个功能，为保证其设计符合分层式结构，可能须要在对应的业务逻辑层和数据訪问层中都添加对应的代码。 　　

3、添加了开发成本。

（三）为什么要使用三层架构

对于一个简单的应用程序来说，代码量不是非常多的情况下，一层结构或二层结构开发全然够用，没有必要将其复杂化，假设对一个复杂的大型系统，设计为一层结构或二层结构开发，那么这种设计存在非常严重缺陷。以下会详细介绍，分层开发事实上是为大型系统服务的。在开发过程中，0基础程序人员出现相似的功能常常复制代码，那么相同的代码写那么多次，不但使程序变得冗长，更不利于维护，一个小小的改动也许会涉及非常多页面，常常导致异常的产生使程序不能正常执行。最基本的面向对象的思想没有得到丝毫的体现，打着面向对象的幌子却依旧走着面向过程的道路。意识到这种问题，0基础程序人员開始将程序中一些公用的处理程序写成公共方法，封装在类中，供其他程序调用。比如写一个数据操作类，对数据操作进行合理封装，在数据库操作过程中，仅仅要类中的对应方法（数据加入、改动、查询等）能够完毕特定的数据操作，这就是数据訪问层，不用每次操作数据库时都写那些反复性 的数据库操作代码。在新的应用开发中，数据訪问层能够直接拿来用。面向对象的三大特性之中的一个的封装性在这里得到了非常好的体现。如今找到了面向对象的感觉，代码量较曾经有了非常大的降低，并且改动的时候也比較方便，也实现了代码的重用性。

四、与MVC的差别

    MVC是三个单词的缩写，分别为：模型(Model),视图(View)和控制Controller)。 MVC模式的目的就是实现Web系统的职能分工。 Model层实现系统中的业务逻辑，通常能够用JavaBean或EJB来实现。 View层用于与用户的交互，通经常使用JSP来实现。 Controller层是Model与View之间沟通的桥梁，它能够分派用户的请求并选择恰当的视图以用于显示，同一时候它也能够解释用户的输入并将它们映射为模型层可运行的操作。

相同是架构级别的，相同的地方在于他们都有一个表现层，可是他们不同的地方在于其它的两个层。 　　

在三层架构中未定义Controller的概念。而MVC也没有把业务的逻辑訪问看成两个层，这是採用三层架构或MVC搭建程序最基本的差别。当然，在三层中也提到了Model，可是三层架构中Model的概念与MVC中Model的概念是不一样的，“三层”中典型的Model层是以实体类构成的，而MVC里，则是由业务逻辑与訪问数据组成的。

五、小结

在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。　所以，分层式设计能够达至例如以下目的：分散关注、松散耦合、逻辑复用、标准定义。一个好的分层式结构，能够使得开发者的分工更加明白。一旦定义好各层次之间的接口，负责不同逻辑设计的开发者就能够分散关注，齐头并进。尽管三层架构仍有不可避免的缺陷，可是软件分层结构使得代码维护很方便，设计明白，各层独立，专注自己擅长的领域。通过这次报告，对软件体系结构又有了更深入的了解。