三层架构
设想我们去餐厅吃饭，我们刚刚坐下来，就会有服务员过来为我们服务。服务员记下我们点的菜，然后将菜单传给厨房的大厨。大厨拿出后勤人员事先买好准备好的菜开始烹制，然后交给服务员端出来让我们享用。其实这个餐厅的饮食服务业务可以分解为三个部分来完成，每一部分各司其职。服务员只管接待顾客、向厨师传递顾客的需求；厨师只管烹炒不同口味、不同特色的美食；后勤工作人员只管提供美食原料。他们三者分工合作共同为顾客提供满意的服务。在餐厅里为顾客提供服务期间，服务员、厨师、后勤工作人员，三者中任何一个人员发生变化时（例如请假或辞职）都不会影响其他俩者的正常工作，只对变化者进行重新调整即可正常营业。
我们软件开发的三层架构与餐厅的服务流程类似。“三层架构”中的“三层”是指：
- 表示层（User Interface Layer-UI)
- 业务逻辑层(BussinessLogic Layer-BLL)
- 数据访问层（Data Access Layer-DAL)。
三层架构的结构可以用如下图表示：
- 表示层：位于系统的最外层（最上层），离用户最近。用于显示数据和接收用户输入的数据，只提供软件系统与用户交互的界面。
- 业务逻辑层：位于表示层和数据访问层之间，专门负责处理用户输入的信息，或者是将这些信息发送给数据访问层进行保存，或者是通过数据访问层从数据库读出这些数据。该层可以包括一些对”商业逻辑“描述的代码在里面。业务逻辑层是表示层和数据访问层之间的桥梁，负责数据处理和传递。开发人员不要在业务逻辑层里写访问数据库的SQL语句。业务逻辑层可以验证用户输入的数据、缓存从数据库中读取的数据等等。
- 数据访问层：仅实现对数据的保存和读取操作。数据访问包括访问数据库系统、二进制文件、文本文档或是XML文档。数据访问层只负责对数据的访问存取工作，最好不要出现任何与业务逻辑和界面设计相关的代码。
三层架构的优缺点
优点：
- 高内聚、低耦合，可以降低层与层之间的依赖。
- 各层互相独立，完成自己该完成的任务，项目可以多人同时开发，开发人员可以只关注整个结构中的其中某一层。
- 容易移植、维护，如 B / S 转 C / S、SQLServer 转 Oracle、添加、修改、删除等。
- 有利于标准化。
- 有利于各层逻辑的复用。
- 安全性高。用户端只能通过业务逻辑层来调用数据访问层，减少了入口点，把很多危险的系统功能都屏蔽了。
三层构架的软件适应性很强,一旦有什么需求变动可以很快的进行代码更改,因而代码的复用性很高。其中一层的代码改变不影响其他层。例如，用户界面的改变并不影响业务逻辑层和数据访问层，甚至访问不同数据库管理系统也只改变数据访问层的代码而不会影响业务逻辑层和表示层的代码。
缺点：
三层架构的缺点就是代码量太多,执行速度慢。三层架构开发模式不适用于对执行速度要求非常高的系统，例如：在线订票，在线炒股等等。它比较擅长于商业规则经常变化的系统。
原博文：