三层体系结构总结（三）

圣诞节那天和两个朋友（两个漂亮的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语句。晕，我白激动了半天。我所见过的结构中对于这一点的处理要么就是牺牲性能保留架构的完整（正如我在《三层体系结构总结（一）》中写的那样），要么就是牺牲架构得到好的性能，我个人还是倾向保留性能的。当然在页面显示设计时尽力保证所显示的一个数据表中的内容是从一个表中读出的。
不知道我现在的理解是否正确？就我的理解是：由于软件架构的限制，有可能会在设计时就考虑对用户功能的限制以及页面显示的内容及显示的方式，尽量把功能操作分解成对单表的原子操作，尽量不要同时操作多张表。这样也可以减少并发性的问题。
最后，此次谈话中还学习到，大型的项目不建议在数据库中使用大量的存储过程，包括一些网上的资料也表明这一点。后来明白这样做是为了减少服务器的工作量。想想也是，其实一个系统中很大一部分操作是对单表进行的填查删改。