三层体系结构总结
所谓三层体系结构，是在客户端与数据库之间加入了一个"中间层"，也叫组件层。 三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。 开发人员可以将应用的商业逻辑放在中间层应用服务器上，把应用的业务逻辑与用户界面分开。在保证客 户端功能的前提下，为用户提供一个简洁的界面。这意味着如果需要修改应用程序代码，只需要对中间层 应用服务器进行修改，而不用修改成千上万的客户端应用程序。从而使开发人员可以专注于应用系统核心 业务逻辑的分析、设计和开发，简化了应用系统的开发、更新和升级工作。对于三层体系结构的设计，不同的人有不同的设计方法，我所见过的几个项目中对三层的不同实现 第一种：三层分别为：DL层，BL层和RL层DL是数据访问层，其中包含的是单表中的字段属性和对此单表的操作（填查删改），类似Java中的entityBean 的概念。每一个单表对应一个 DLBL是业务逻辑层，其中包含的是业务逻辑，一个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和De partID，Employee表中只有Employee的信息。我个人感觉这样做的好处是：在开发的深入时，不会 因为Employee关联的信息的增多而造成Employee表的膨胀，且Employee表的架构是固定的。但是 我觉得这样做，在查询时信息间联接会多一倍。如：要显示一条人员记录并显示他所在的部门，此时就要 三张表集连查询，如果在Employee表中加入外键就可以减少一张表的集连。再来说说持久层，他们所说的持久层，我理解就是数据访问层。当然这一层中还分了三个小层。有一个业 务层和持久层的接口层（叫DAO）。比较吸引我的还是EO这一层。每一个数据表对应一个E0,在一个 EO中只有一些公有属性，这些属性就是对应相应表中的字段，我的理解就是在数据库的外面包了一层。 此时就接触到了一个我比较关心的问题，对于业务上集连的查询是如何处理的。得到的结论是：他们大多 查询都是对单表的查询。如果有较复杂的查询时直接写Sql语句。晕，我白激动了半天。我所见过的结构 中对于这一点的处理要么就是牺牲性能保留架构的完整（正如我在三层体系结构总结（一）中写的那 样），要么就是牺牲架构得到好的性能，我个人还是倾向保留性能的。当然在页面显示设计时尽力保证所 显示的一个数据表中的内容是从一个表中读出的。不知道我现在的理解是否正确？就我的理解是：由于软件架构的限制，有可能会在设计时就考虑对用户功 能的限制以及页面显示的内容及显示的方式，尽量把功能操作分解成对单表的原子操作，尽量不要同时操 作多张表。这样也可以减少并发性的问题。最后，此次谈话中还学习到，大型的项目不建议在数据库中使用大量的存储过程，包括一些网上的资料也 表明这一点。后来明白这样做是为了减少服务器的工作量。想想也是，其实一个系统中很大一部分操作是 对单表进行的填查删改。00（请您对文章做出评价）posted on 2005-12-28 11:31 KiddLee阅读（1098）评论（1）编辑收藏网摘所属分类：架构设计BLLp1 lixuuL u 0DAL*IDALlOperaLiunDB()lOperaLiunDB()在编码中体会到这个架构有以下几个优点:IBLL三层体系结构总结（四）前一段时间帮一个项目组做他们的项目，有幸了解了一下他搭建的架构。相比起以前所见过的架构, 我觉得这个应该算是不错的。大体结构如下图：ModelUtility;4d 11Opera Li on t.)'m 卑 mfUT1、层与层之间依赖于接口:（请您对文章做出评价）2、在系统中往往会存在很多的状态，将这些状态提取出来，作为一个单独的项目，可以使用枚举来 封装，可以提高代码的可读性，也给今后做这件事的人以方便,而且可以到达统一的效果.3、系统中的综合查询部分，对于结果的传递没有使用实体类进行传递，后来感觉综合查询本身就很 灵活多变，用实体类去传递结果，显得有些困难。而且结果集本身就是依靠多个实体及实体间关 系得出，又如何用一个实体去传递。即使对于每一个查询建立一个实体，对于今后的改动又如何 很好的应对呢项目中的一些遗憾：开始想使用Castle中的AR建立ORM，但是出了一些问题，应该算是有些遗憾吧。所以后来自己去写 实体中的关系，有些地方还是有些牵强，今后要加强学习00(请您对文章做出评价)posted on 2007-02-16 18:37 Kid川ee阅读(915)评论(2)编辑收藏网摘所属分类：架构设计三层体系结构总结(六)Model类型：加入两个构造函数 付值和缺省去掉ModelList类型，使用ListvModel代替，可以在相应的Model中加入得到List的方法对于有关系的列表，还是使用DataSet比较方便DAL对于读取数据，不必加入TryCatch对于操作数据库时出现的问题可以使用自定义的异常处理方式 使用Partial将带有业务逻辑的方法和普通的添查删改方法分开BLL 加入缺省构造函数和对应DAL实例使用Partial将带有业务逻辑的方法和普通的添查删改方法分开UI按模块划分，设置文件夹最外层只留下公共页面，如Login, Error Page添加和编辑可以使用同一页面，对于添加时的主键可以设置为0,在BLL层中判断具体调用DAL中的什 么方法对于传递的参数，最好使用对称加密方式，提高安全性自定义异常处理在这点时间的项目中，发现有些异常被抛出后，不能正常抛到报错页面进行处理，实际上可以在Catch的 时候进行处理，记录错误在这次项目中发现如果是post back时发生异常，应用程序是不能重新转向报错页面的，所以使用自定义 的异常处理权限控制对于操作权限和浏览现在还是分成两套页面，不过现在有一种想法是对于操作按钮在初始化界面时进行权 限判断，以减小页面数量00(请您对文章做出评价)posted on 2008-06-04 13:59 Kidriiee阅读(541)评论(2)编辑收藏网摘所属分类：架构设计
