三层体系结构总结
所谓三层体系结构，是在客户端与数据库之间加入了一个"中间层"，也叫组件层。
三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。
开发人员可以将应用的商业逻辑放在中间层应用服务器上，把应用的业务逻辑与用户界面分开。在保证客户端功能的前提下，为用户提供一个简洁的界面。这意味着如果需要修改应用程序代码，只需要对中间层应用服务器进行修改，而不用修改成千上万的客户端应用程序。从而使开发人员可以专注于应用系统核心业务逻辑的分析、设计和开发，简化了应用系统的开发、更新和升级工作。
对于三层体系结构的设计，不同的人有不同的设计方法，我所见过的几个项目中对三层的不同实现
第一种：
三层分别为：DL层，BL层和RL层
DL是数据访问层，其中包含的是单表中的字段属性和对此单表的操作（填查删改），类似Java中的entity Bean的概念。每一个单表对应一个DL
BL是业务逻辑层，其中包含的是业务逻辑，一个BL下引用很多的DL，实现对单表的组合查询及操作，要注意此层涉及到数据库的架构，在设计数据库时，要实现数据表之间是主表与子表的关系。例如：T_Employee雇员表，T_Part部门表，T_Position职位表，T_Site办公地点表
主表是T_Employee雇员表，T_Part部门表，T_Position职位表，T_Site办公地点表为子表
对于表的综合查询方法是：
先对主表查询，调用主表所对应的DL。再根据主表的记录分别对每一个子表进行查询。将自表的查询结果添加的主表后，形成一个大的查询集合。
对于表的操作（增删改）
此时只对主表进行操作，调用主表对应的DL中的操作方法。
RL层是逻辑判断层，主要是对页面上传入的数据进行逻辑判断。RL层之上就是UI
个人感觉此种架构要在数据库设计上注意表之间的关系，尽力满足主与子的关系。在功能上对用户要有一定的限制，不要表现在对于子表的删除操作一定要慎重，以免造成主表与子表的数据在逻辑上出现的主表的外键在子表中没有相对应的值。
第二种我所见过的三层设计模式是：
还是分为UI层、业务层（BLL）、数据访问层（DAL），但其中的数据的存储和传递使用的是Model类，Model类中只有私有字段和公有的属性，并不存在对数据的操作，定义逻辑业务实体，但是实体的定义并不是以单表定义的，而是以一个业务逻辑来定义。
我所遇到的问题是，随着开发的深入，对用户需求的深入，需求在变化，大多是需求膨胀，就某一个逻辑业务实体来说就会不断地膨胀。这样为了实现一个操作有可能要实例化一个很大的实体类，而实际上这个实体类中有用的信息并不多。这样就会造成整体性能的下降。
圣诞节那天和两个朋友（两个漂亮的mm）在上岛咖啡谈论N层架构的实现。他们单位用的是Java，架构是较为严格按照J2EE的模式。当然一共分了七层（我的天！好大的程序）。听完他们的描述，我还是把这七层合并为三层理解（DAL、BLL、UI）。只是实现方式不同。从中也学到了一些东西。
先说UI，Web层中的页面跳转使用的是config文件配置的。例如：当A页面要跳转到B页面时，会执行一些函数或操作得到一个forward的值，根据这个forward的值到相应的Web层的config文件中寻找它应该到哪个页面。用此种方法的好处是使页面跳转十分灵活。这时我想起了我们在作页面跳转时会把代码写到页面的cs或aspx中，如果有几个页面都要跳转到同一个指定页面时，就要在这些页面中写一些代码，如果这个指定的页面名称变了，就要将这几个页面的的跳转代码全部修改一遍。他们这样做的确不错。
再说业务层，说到业务层就要说到业务逻辑，此时不得不涉及到数据库表结构。他们在表结构上不提倡使用外键，一般使用Link关系表作联接。如：Employee表和Department表，在Employee表中不会有DepartID作为外键，而是使用EmployeeDepartLink表作联接，在关系表中只有EmployeeID和DepartID，Employee表中只有Employee的信息。我个人感觉这样做的好处是：在开发的深入时，不会因为Employee关联的信息的增多而造成Employee表的膨胀，且Employee表的架构是固定的。但是我觉得这样做，在查询时信息间联接会多一倍。如：要显示一条人员记录并显示他所在的部门，此时就要三张表集连查询，如果在Employee表中加入外键就可以减少一张表的集连。
再来说说持久层，他们所说的持久层，我理解就是数据访问层。当然这一层中还分了三个小层。有一个业务层和持久层的接口层（叫DAO）。比较吸引我的还是EO这一层。每一个数据表对应一个EO，在一个EO中只有一些公有属性，这些属性就是对应相应表中的字段，我的理解就是在数据库的外面包了一层。
此时就接触到了一个我比较关心的问题，对于业务上集连的查询是如何处理的。得到的结论是：他们大多查询都是对单表的查询。如果有较复杂的查询时直接写Sql语句。晕，我白激动了半天。我所见过的结构中对于这一点的处理要么就是牺牲性能保留架构的完整（正如我在《三层体系结构总结（一）》中写的那样），要么就是牺牲架构得到好的性能，我个人还是倾向保留性能的。当然在页面显示设计时尽力保证所显示的一个数据表中的内容是从一个表中读出的。
不知道我现在的理解是否正确？就我的理解是：由于软件架构的限制，有可能会在设计时就考虑对用户功能的限制以及页面显示的内容及显示的方式，尽量把功能操作分解成对单表的原子操作，尽量不要同时操作多张表。这样也可以减少并发性的问题。
最后，此次谈话中还学习到，大型的项目不建议在数据库中使用大量的存储过程，包括一些网上的资料也表明这一点。后来明白这样做是为了减少服务器的工作量。想想也是，其实一个系统中很大一部分操作是对单表进行的填查删改。
三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。
开发人员可以将应用的商业逻辑放在中间层应用服务器上，把应用的业务逻辑与用户界面分开。在保证客户端功能的前提下，为用户提供一个简洁的界面。这意味着如果需要修改应用程序代码，只需要对中间层应用服务器进行修改，而不用修改成千上万的客户端应用程序。从而使开发人员可以专注于应用系统核心业务逻辑的分析、设计和开发，简化了应用系统的开发、更新和升级工作。
对于三层体系结构的设计，不同的人有不同的设计方法，我所见过的几个项目中对三层的不同实现
第一种：
三层分别为：DL层，BL层和RL层
DL是数据访问层，其中包含的是单表中的字段属性和对此单表的操作（填查删改），类似Java中的entity Bean的概念。每一个单表对应一个DL
BL是业务逻辑层，其中包含的是业务逻辑，一个BL下引用很多的DL，实现对单表的组合查询及操作，要注意此层涉及到数据库的架构，在设计数据库时，要实现数据表之间是主表与子表的关系。例如：T_Employee雇员表，T_Part部门表，T_Position职位表，T_Site办公地点表
主表是T_Employee雇员表，T_Part部门表，T_Position职位表，T_Site办公地点表为子表
对于表的综合查询方法是：
先对主表查询，调用主表所对应的DL。再根据主表的记录分别对每一个子表进行查询。将自表的查询结果添加的主表后，形成一个大的查询集合。
对于表的操作（增删改）
此时只对主表进行操作，调用主表对应的DL中的操作方法。
RL层是逻辑判断层，主要是对页面上传入的数据进行逻辑判断。RL层之上就是UI
个人感觉此种架构要在数据库设计上注意表之间的关系，尽力满足主与子的关系。在功能上对用户要有一定的限制，不要表现在对于子表的删除操作一定要慎重，以免造成主表与子表的数据在逻辑上出现的主表的外键在子表中没有相对应的值。
第二种我所见过的三层设计模式是：
还是分为UI层、业务层（BLL）、数据访问层（DAL），但其中的数据的存储和传递使用的是Model类，Model类中只有私有字段和公有的属性，并不存在对数据的操作，定义逻辑业务实体，但是实体的定义并不是以单表定义的，而是以一个业务逻辑来定义。
我所遇到的问题是，随着开发的深入，对用户需求的深入，需求在变化，大多是需求膨胀，就某一个逻辑业务实体来说就会不断地膨胀。这样为了实现一个操作有可能要实例化一个很大的实体类，而实际上这个实体类中有用的信息并不多。这样就会造成整体性能的下降。
圣诞节那天和两个朋友（两个漂亮的mm）在上岛咖啡谈论N层架构的实现。他们单位用的是Java，架构是较为严格按照J2EE的模式。当然一共分了七层（我的天！好大的程序）。听完他们的描述，我还是把这七层合并为三层理解（DAL、BLL、UI）。只是实现方式不同。从中也学到了一些东西。
先说UI，Web层中的页面跳转使用的是config文件配置的。例如：当A页面要跳转到B页面时，会执行一些函数或操作得到一个forward的值，根据这个forward的值到相应的Web层的config文件中寻找它应该到哪个页面。用此种方法的好处是使页面跳转十分灵活。这时我想起了我们在作页面跳转时会把代码写到页面的cs或aspx中，如果有几个页面都要跳转到同一个指定页面时，就要在这些页面中写一些代码，如果这个指定的页面名称变了，就要将这几个页面的的跳转代码全部修改一遍。他们这样做的确不错。
再说业务层，说到业务层就要说到业务逻辑，此时不得不涉及到数据库表结构。他们在表结构上不提倡使用外键，一般使用Link关系表作联接。如：Employee表和Department表，在Employee表中不会有DepartID作为外键，而是使用EmployeeDepartLink表作联接，在关系表中只有EmployeeID和DepartID，Employee表中只有Employee的信息。我个人感觉这样做的好处是：在开发的深入时，不会因为Employee关联的信息的增多而造成Employee表的膨胀，且Employee表的架构是固定的。但是我觉得这样做，在查询时信息间联接会多一倍。如：要显示一条人员记录并显示他所在的部门，此时就要三张表集连查询，如果在Employee表中加入外键就可以减少一张表的集连。
再来说说持久层，他们所说的持久层，我理解就是数据访问层。当然这一层中还分了三个小层。有一个业务层和持久层的接口层（叫DAO）。比较吸引我的还是EO这一层。每一个数据表对应一个EO，在一个EO中只有一些公有属性，这些属性就是对应相应表中的字段，我的理解就是在数据库的外面包了一层。
此时就接触到了一个我比较关心的问题，对于业务上集连的查询是如何处理的。得到的结论是：他们大多查询都是对单表的查询。如果有较复杂的查询时直接写Sql语句。晕，我白激动了半天。我所见过的结构中对于这一点的处理要么就是牺牲性能保留架构的完整（正如我在《三层体系结构总结（一）》中写的那样），要么就是牺牲架构得到好的性能，我个人还是倾向保留性能的。当然在页面显示设计时尽力保证所显示的一个数据表中的内容是从一个表中读出的。
不知道我现在的理解是否正确？就我的理解是：由于软件架构的限制，有可能会在设计时就考虑对用户功能的限制以及页面显示的内容及显示的方式，尽量把功能操作分解成对单表的原子操作，尽量不要同时操作多张表。这样也可以减少并发性的问题。
最后，此次谈话中还学习到，大型的项目不建议在数据库中使用大量的存储过程，包括一些网上的资料也表明这一点。后来明白这样做是为了减少服务器的工作量。想想也是，其实一个系统中很大一部分操作是对单表进行的填查删改。
