三层架构理论篇

         对于三层架构的理论阐述，我将从三个大的方面去讨论：what、why和how，说白了也就是以三层架构为中心，去了解什么是三层，为什么用三层以及怎么用三层这个三个问题。OK，废话不多说，进入正题。

         什么是三层架构？（What）

         通常多层结构的划分方式有两种：分别是物理和逻辑。物理上的三层结构是指将整个应用系统分为显示层、业务层和数据层，并且这三个层面上的实体都是硬件，比如显示层就是客户机器，业务层通常是应用程序服务器，而数据层就是数据库服务器了。

         今天我们讨论的主要是逻辑上的三层架构，是在软件设计时将软件的业务应用划分为：表现层（UI）、业务逻辑层（BLL）和数据访问层（DAL）。在软件体系架构中，分层式结构是最常见、也是最重要的一种结构。下面我们来看看这三层的具体含义和作用是什么。

         表现层（UserInterface），还有一个概念叫做表示层（User Show Layer），无论叫什么吧，它们表达的意思基本上是一样的：一般来讲就是指展现给用户的界面，即用户在使用一个系统时的所见所得。这层的作用是向用户展现特定的业务数据，同时采集用户的输入信息和操作，主要表示为Web方式，也可以表示为Winform方式，位于系统的最上层，最接近用户，为用户提供了一种交互式操作的界面。

         业务逻辑层（BusinessLogic Layer）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑进行处理。如果说数据层是各种蔬菜原材料，那么业务逻辑层就是做菜。同时业务逻辑层也是一座桥梁，负责连接UI和DAL，使它们能够很好的通信，从而完成系统的功能。它的作用有：从DAL中获取数据，以供UI显示用；从UI中获取用户指令和数据，执行业务逻辑；从UI中获取用户指令和数据，通过DAL写入数据库中。

         数据访问层（DataAccess Layer）：该层直接跟数据库打交道，主要操作就是对数据库进行增添、删除、修改和查找等。需要强调的一点是，数据访问层不是指存储原始数据的数据库，而是对数据的一些操作，具体为BLL或者UI提供数据服务。它的作用是：负责对数据库的访问，可以访问数据库系统，二进制文件，文本文档或者是XML文档。

         至此我们已经了解了三层架构中每一层的含义和作用，但是仅仅有三层架构并不能让系统跑起来，因为层与层之间的通信问题是很复杂的，如果单靠参数传递进行通信那是非常麻烦的一件事情，因此我们要引入实体层，也就是数据模型，各层都引用数据模型，从而实现各层之间的数据传递和通信，说白了实体层就是一个数据结构体，里面是一些字段属性。

         说了这么多，也许大家对三层架构还是没有一个形象的认识，笔者从网上找了一张不错的图，希望可以帮助大家更好的理解三层架构。

        

         这张图很好的描述了各层之间的依赖关系，只是没有画出数据库（DB），那样的话就很容易让大家区分数据层和数据访问层这两个不同的的概念了。

         为什么使用三层架构？（Why）

         分层的目的是想将复杂问题简单化，也就是面向对象技术所崇尚的“高内聚，低耦合”。当一个项目过于复杂且涉及数据访问和存储的问题时，你就要考虑将整个业务应用进行分层，使用三层架构将业务简化，从而更好的设计和开发应用系统。

         将一个大型项目分层有很多的优势：首先，开发人员只需要关注整个系统结构汇总的某一层即可，其他的不需要去考虑，并且这样可以很容易的实现系统的升级，只需要用新的实现替换原有层次的实现即可，其他的层次不用动，在后期的维护过程中，极大地降低了维护成本和时间；其次，可以大大的降低层与层之间的依赖，有利于封装各层的实现，便于各层逻辑的复用；最后，分层也有利于标准化，使系统的结构更加的明确。

         当然，分层也有其自身的缺点：第一，分层降低了系统的性能，本来很多业务可以直接访问数据库，现在却要从中间层BLL绕一下，比较麻烦；第二，在某些情况下会导致连锁反应，比如你要在UI增加一个功能，为了保证分层结构，就要在相应的BLL和DAL中都加入相应的代码，麻烦；第三，增加了开发成本，这是显然的。

         如何使用三层架构？（How）

         三层架构的具体代码实现的例子，将在下篇博文中重点介绍，本次我们主要讨论在使用三层架构过程中要注意的一些原则或者说是规则。考虑一个项目是不是应该使用三层或者多层设计时，首先考虑是不是真的有必要？如何你的项目逻辑业务简单，甚至对数据库访问都没有，那完全没必要用三层架构啊。

         即便是说你要使用三层架构，但不是说你把项目分成DAL、BLL和UI三个模块，就叫三层了，NO！在参考百度百科时，里面有几个问题值得思考

        1.      UI里面只有少量（或者说没有）SQL语句或者存储过程调用，并且你能保证这些语句不会修改数据，越俎代庖？

        2.      如果把你设计的UI拿掉，你的项目还能在Interface或者API的层次上提供所有功能吗？

        3.      你的DAL可以移植到其他类似的环境的项目中接着运行吗？

        4.      你所设计的三个模块，能否部署在不同的服务器上？

        如果你的答案不都是YES，那么恭喜你：你的设计还不能算是严格意义上的三层结构。因为三层结构的程序需是有一些约定遵守的规则或者说是原则的：

        DAL只提供基本的数据访问，不包含任何与业务相关的逻辑处理；

        UI只负责显示和采集用户操作，不包含任何的业务相关的逻辑处理；

        BLL负责处理业务逻辑，通过获取UI传来的操作指令，决定执行业务逻辑，在需要访问数据库的时候直接交给DAL处理，处理完成之后，返回必要的数据给UI。

        还有一点值得注意的是，我们在做设计的时候一定要从BLL出发，而不要从UI出发，所有的业务逻辑都应该在BLL层实现，并且是以面向对象的方式实现。

        至此，相信大家对三层架构有了一个基本的了解，当时要想在实际应用中灵活地去使用三层，还是比较困难的，需要我们不断的去思考，去实践，慢慢的摸索才能够将三层的优势发挥出来。