三层架构

    刚接触三层，感觉很神奇，写篇博客总结下

一.三层的由来

    有三层，就有最初的单层和双层，

    单层结构是80年代以来小型应用的结构，在那个结构化编程充斥的时代，还没有出现架构的概念，典型的是基于Dbase、Foxbase等小型数据库的应用。

    双层结构可以理解为传统的客户/服务器结构，尽管是目前占统治地位的结构，但是因其封装移植等方面的缺陷，已使它步入暮年，典型的是基于Oracle、Infomix等大型数据库的C/S应用。如下图

   

    两层结构的特点有：

        1.数据库访问和用户界面判断逻辑放在一起实现

        2.用户界面层直接访问数据库

        3.整个系统功能放在同一项目中

    也就是说传统的两层结构的特点是用户界面层直接与数据库进行交互，还要进行业务规则、合法性校验等工作。

这种结构存在着很多局限性:

比如:一旦用户的需求发生变化，应用程序都需要进行大量修改，甚至重新开发，给系统的维护和升级带来了极大的不便；其次，用户界面层直接访问数据库，会带来很多安全隐患。

写到这里，突然想起以SQL Server 2008为数据库，基于过程的VB6.0为开发语言，文件DSN为数据源的学生信息管理系统和机房收费系统就是两层结构。

为了克服两层结构的局限性提出了三层结构

    三层结构是传统的客户/服务器结构的发展，代表了企业级应用的未来，典型的有Web下的应用。

    多层结构和三层结构的含义是一样的，只是细节有所不同。之所以会有双层、三层这些提法，是因为应用程序要解决三个层面的问题。

    所谓三层体系结构，是在客户端与数据库之间加入了一个“中间层”，也叫组件层。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。
    中间层通常包括业务逻辑层（Business Logic Layer，简称BLL）、数据访问层（Database Access Layer，简称DAL）和数据对象模型层（Database Object Model Layer，简称DOM）。

    也就是下图所示结构

二.各层的作用

    用户界面（User Interface，简称UI），表示层，位于最上层，用于显示和接收用户提交的数据，为用户提供交互式的界面。表示层一般为Windows窗体或Web界面。根据用户的具体需求，为每个功能模块，部署输入控件、操作控件和输出控件，并调用业务逻辑层中类的方法实现功能。

    业务逻辑层是表示层和数据访问层之间沟通的桥梁，主要负责数据的传递和处理。为用户的每个功能模块，设计1个业务逻辑类，此时，需要利用相关的数据访问层类中，记录操作方法的特定集合，来实现每个逻辑功能。

    数据访问层主要实现对数据的读取、删除和写入等操作。使用ADO.NET中的数据操作类，为数据库中的每个表，设计1个数据访问类。类中实现：记录的插入、删除、单条记录的查询、记录集的查询、单条记录的有无判断等基本的数据操作方法。对于一般的管理信息软件，此层的设计是类似的，包含的方法也基本相同。此层的任务是：封装每个数据表的基本记录操作，为实现业务逻辑提供数据库访问基础。

    数据对象模型层即业务实体层。主要用于表示数据存储的持久对象。在实际应用程序中的实体类是跟数据库中的表相对应的，也就是说一个表会有一个对应的实体类。当然有些三层结构并不包含单独的数据对象模型层，而将其功能分解到业务逻辑层和数据访问层之中。

三、各层之间的调用关系

    数据访问层的类，直接访问数据库，实现基本记录操作。
    业务逻辑层的类，调用相关的数据访问类，实现用户所需功能。
    界面层：部署控件后，调用业务逻辑层的类，实现功能。
    

四、ORM对象关系映射

    Object Relational Mapping，简称ORM，是为了解决面向对象的类，与关系数据库的表之间，存在的不匹配的现象，通过使用描述对象和关系之间映射的元数据，在程序中的类对象，与关系数据库的表之间建立持久的关系，用于在程序中描述数据库表。本质上就是将数据从一种形式转换到另外一种形式

    将表中的每个字段抽取为类的字段（注意类型匹配），并封装成属性，设计构造函数，来将表抽取为类。这种类就称为实体类。这个抽取过程称为对象关系映射ORM。

    ORM是一个广义的概念，适应于关系数据库与应用程序之间的各类数据转换，目前有许多自动转换工具可用，如codesmith 。

    见上图，Common项目中一般放的是公用文件，如数据操作类DBHelper等，被数据访问层的类调用；Modal项目中存放的是实体类，在Modal项目中，为数据库的每个表，都设计一个相应的实体类，这样，就相当于对每个表实体，在.NET程序中，都可以通过类对象来应用。

五、三层和MVC的区别（简单描述）

    MVC（模型Model-视图View-控制器Controller）是一种设计模式，我们可以用它来创建在域对象和UI表示层对象之间的区分。 
　　同样是架构级别的，相同的地方在于它们都有一个表现层，但是他们不同的地方在于其他的两个层。 
    在三层架构中没有定义Controller的概念。而MVC也没有把业务的逻辑访问看成两个层，这是采用三层架构或MVC设计程序最主要的区别。当然在三层中也提到了Model，但是三层架构中Model的概念与MVC中Model的概念是不一样的，“三层”中典型的Model层是以实体类构成的，而MVC里，则是由业务逻辑与访问数据组成的。


六、三层结构优点
    三层结构是基于模块化程序设计的思想，为实现分解应用程序的需求，而逐渐形成的一种标准模式的模块划分方法。主要体现出对程序分而治之的思想：数据访问层只负责提供原始数据，并不需要了解业务逻辑；业务逻辑层调用数据访问层提供的方法自定义一些业务逻辑，对数据进行加工，本身不需要了解数据访问层的实现；表示层直接调用业务逻辑提供的方法把数据呈现给用户。

    三层结构的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，再经由中间层与数据库进行交互，这样会大大提高系统的安全性。
    它的优点在于不必为了业务逻辑上的微小变化而迁至整个程序的修改，只需要修改商业逻辑层中的一个函数或一个过程；增强了代码的可重用性；便于不同层次的开发人员之间的合作，只要遵循一定的接口标准就可以进行并行开发了，最终只要将各个部分拼接到一起构成整体应用程序
    三层结构的应用程序更能够适应企业级应用日益增长的复杂度和灵活性的要求，并且通过软件分层的高内聚、低耦合原则，实现扩展、维护和重用的要求，可以大大提高开发效率。

七、总结

    将应用程序的实现分布在3层实现。设计数据访问层实现对数据表的基本操作，为每个数据表设计1个数据访问类。为用户的每个功能模块设计1个业务逻辑类，通过调用相关的数据访问层类，来实现每个业务逻辑功能。在界面层，首先部署控件，然后在恰当控件的恰当事件里，调用相关的业务逻辑类，实现界面上的设计功能。另外，还需要的是存放实体类的项目Modal和存放通用数据操作类的项目Common。
    将应用程序的功能分层后，一旦用户的业务需求改变，对于固定的DBMS，数据访问层基本可以不变，其次修改业务逻辑层，界面层稍做改动即可，整个应用程序的总体架构是不受影响的。这种做法使程序的可复用性、可修改性，都得到了很好的改善，大大提高了软件工程的效率。

    在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。分层式设计可以达至如下目的：分散关注、松散耦合、逻辑复用、标准定义。一个好的分层式结构，可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口，负责不同逻辑设计的开发人员就可以分散关注，齐头并进。虽然三层架构仍有不可避免的缺陷，但是软件分层结构使得代码维护非常方便，设计明确，各层独立，专注自己负责的领域。