在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。三层结构从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层。
哪三层
三层架构设计主要是对于——>表示层（UI）、业务逻辑层（BLL）和数据访问层（DAL）这三个层面的架构设计。
表示层
表示层就是我们看到一个东西的样子，也就是好不好看就取决于UI的设计。
通俗讲就是展现给用户的界面，用于显示数据和接受用户输入的数据；即用户在使用一个系统的时候他的所见所得。
逻辑层
这里的逻辑层是业务的逻辑，以合适的逻辑来对数据进行操作与传递。
针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。是表示层和数据访问层之间的桥梁。
数据访问层
数据服务层简单明了，它的任务就是直接对数据库进行增删改查。
该层所做事务直接操作数据库，针对数据的增添、删除、修改、查找等。
为什么要分层架构
- 避免了表示层直接访问数据访问层，表示层只和业务逻辑层有联系，提高了数据安全性。
- 有利于系统的分散开发，每一个层可以由不同的人员来开发，只要遵循接口标准，利用相同的对象模型实体类就可以了，这样就可以大大提高系统的开发速度。
- 方便系统的移植，如果要把一个 C/S 的系统变成 B/S 系统，只要修改三层架构的表示层就可以了，业务逻辑层和数据访问层几乎不用修改就可以轻松的把系统移植到网络上。
- 项目结构更清楚，分工更明确，有利于后期的维护和升级。
俗话说要学会把学习与生活结合，把学习和生活联系，这样的学习才叫会学习，会生活。我们举个生活中的例子来理解三层： 我们举一个生活中的例子
- 服务员：只管接待客人；
- 厨师：只管做客人点的菜；
- 采购员：只管按客人点菜的要求采购食材；
他们各负其职，服务员不用了解厨师如何做菜，不用了解采购员如何采购食材；厨师不用知道服务员接待了哪位客人，不用知道采购员如何采购食材；同样，采购员不用知道服务员接待了哪位客人，不用知道厨师如何做菜。
与传统的双层架构区别
为什么会诞生三层架构思维呢？
那肯定是因为对于传统的架构模式，出现了一些缺陷或者麻烦。
简单来说，就是为了解除复杂的耦合关系，即解耦
举个例子，比如，服务员（UI层）服务态度不好——另找服务员；厨师（BLL层）辞职——招聘另一个厨师；采购员（DAL）辞职——招聘另一个采购员；
任何一层发生变化都不会影响到另外一层！！！
优点
我直接列出来，因为百度也可以搜到。
- 高内聚、低耦合，可以降低层与层之间的依赖。
- 各层互相独立，完成自己该完成的任务，项目可以多人同时开发，开发人员可以只关注整个结构中的其中某一层。
- 容易移植、维护，如 B / S 转 C / S、SQLServer 转 Oracle、添加、修改、删除等。
- 有利于标准化。
- 有利于各层逻辑的复用。
- 安全性高。用户端只能通过业务逻辑层来调用数据访问层，减少了入口点，把很多危险的系统功能都屏蔽了。
三层如何连接
我们上面说了，每一层都各负其责，那么该如何将三层联系起来呢？
这里你可能觉得自相矛盾了，其实是因为还有一个东西，我们漏了。
不能直接联系，还不允许间接联系吗？
Entity(实体层)：它不属于三层中的任何一层，但是它是必不可少的一层。
为什么说必不可少呢？因为三层是没有直接联系的，间接联系就全靠它了。
Entity在三层架构中的作用：
- 1、实现面向对象思想中的"封装";
- 2、贯穿于三层，在三层之间传递数据;（注：确切的说实体层贯穿于三层之间，来连接三层）
- 3、对于初学者来说，可以这样理解：每张数据表对应一个实体，即每个数据表中的字段对应实体中的属性（注：当然，事实上不是这样。为什么？1＞，可能我们需要的实体在数据表对应的实体中并不存在；2＞，我们完全可以将所有数据表中的所有字段都放在一个实体里）
- 4、每一层（UI—>BLL—>DAL）之间的数据传递（单向）是靠变量或实体作为参数来传递的，这样就构造了三层之间的联系，完成了功能的实现。
网上找了张关系图：
最大的优势
说了这么多，实际上这种架构模式的诞生就是为了解决传统架构复杂的耦合关系。
最大的优势也就是任何一层发生变化都不会影响到另外一层！！！
