参考：https://blog.csdn.net/clb929/article/details/54295211
https://blog.csdn.net/wslbxx/article/details/38554537
https://blog.csdn.net/dinghaoseu/article/details/50322171
由于层是一种弱耦合结构，层与层之间的依赖是向下的，底层对于上层而言是“无知”的，改变上层的设计对于其调用的底层而言没有任何影响。如果在分层设计时，遵循了面向接口设计的思想，那么这种向下的依赖也应该是一种弱依赖关系。因而在不改变接口定义的前提下，理想的分层式架构，应该是一个支持可抽取、可替换的“抽屉”式架构。正因为如此，业务逻辑层的设计对于一个支持可扩展的架构尤为关键，因为它扮演了两个不同的角色。对于数据访问层而言，它是调用者；对于表示层而言，它却是被调用者。依赖与被依赖的关系都纠结在业务逻辑层上，如何实现依赖关系的解耦，则是除了实现业务逻辑之外留给设计师的任务。
三层架构(3-tier application)通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。区分层次的目的即为了“高内聚，低耦合”的思想。
使用动软快速生成的简单三层模型项目主要有以下：
BLL--业务逻辑层，所有的业务逻辑全部写在这里，动软已经为每个表自动生成了一个业务类，类名就是表名，BasicMethod区段是自动生成的一些基础方法，比如增删改查、分页查询这些，ExtensionMethod区段是空的，我们自己写的业务代码写在这个区段。
DAL--数据访问层，所有的数据库访问的基础方法写在这里，动软已经为每个表自动生成了一个数据访问类，类名就是表名，BasicMethod区段是自动生成的一些基础方法，比如增删改查、分页查询这些，ExtensionMethod区段是空的，如果我们觉得这些基础的数据库操作方法不够用，可以在这个区段添加自己的数据库操作方法，但是只有数据库的操作方法应该写在DAL类库。
DBUtility--数据库访问的基础类库，封装了MySql，Sql，OLE，SqlLite，Oracle等数据库访问的方法，与ADO.NET相关的connection，DataAdapter，Command等全部在这里，DAL是在DBUtility基础上的进一步封装的，这个类库基本不需要修改。
Model--数据库表结构的映射，每一个类名代表数据库中的一个相同名字的表，类的每一个字段、属性表示表中对应的字段，数据库的一条记录就对应类的一个对象，这个类库基本不需要修改。