再谈业务逻辑架构模式(事务脚本，表模块，活动记录，领域模型)

　　前几天写过一遍博文：业务逻辑架构模式(事务脚本，表模块，活动记录，领域模型) ，此文仅对常用的设计方式进行了一个大概的描述，感觉意犹未尽。经过几天的研究查证与思考，又有些新的认识。

虽然说这是四种独立的架构模式，但是他们之间并不是毫无关联的。除去在大型软件中很少使用的表模块，事务脚本与活动记录经常交叉使用，活动记录与领域模型也是互通有无。先说前者。

活动记录的优点很多，缺点也很明显。最大的缺点就是由于是一张表对应一个模型，业务操作基本上都是基于单表的。当发生跨表逻辑时，就无法应付了，这时只好求助于事务脚本，有时直接在Model里写事务脚本，有时则在Model的上方建立一个XXXHandler或XXXManage来实现事务脚本。如果对象间的关联越来越多, 你的事务脚本越来越庞大, 重复的代码越来越多，项目就不可控了。

对于领域模型，其构建模式并不是一成不变的，其很多变种就与活动记录比较类似。常规的方式，是领域模型直接与数据库映射，中间没有其它层。但是也有这样一个变种，在数据库与领域模型间加入实体层，每一个实体对应一张表，领域模型以继承或重新编写的方式构建于实体之上。实体仅有数据，其CRUD由上层或其它对象完成，或者实体可以自行实现自己的CRUD，领域模型则通过操作各个实体的CRUD来完成业务逻辑。后面的一种架构方式，不就很象活动记录+领域模型的架构吗

下面再继续看看领域模型。如下图：



在整个软件架构过程中，BO（业务对象）通过DAO（数据访问对象）操作PO（持久对象）来实现业务逻辑。对于VO（页面展示对象），在单表情况下多是直接展示PO，多表情况下多是将多个PO对象合并成一个DTO（数据传输对象）再进行展示。对于实体仅有数据，其CRUD由上层或其它对象完成的这种情况，BO包含DAO对象。对于实体自行实现自己的CRUD，BO与PO对象都包含DAO对象。

具体到技术层面的选择，ActiveRecord能很好的实现活动记录模式，NHibernate对于活动记录与领域模型都有很好的支持，园子里的MySoft也是一个比较有特点的集活动记录与事务脚本于一体的框架，微软的企业库与园子里的yueue.ADOKeycap则是很好的事务脚本框架。

其实对于这些架构的问题，我还有很多细节方面的疑问，各位高手看过后如果发现我说错了，尽情拍砖纠正，让我在思想碰撞的火花中成长。

参考的文章：

面向对象的NHibernate数据查询语言-HQL

PO BO VO DTO POJO DAO概念及其作用（附转换图）

java术语（PO/POJO/VO/BO/DAO/DTO）ActiveRecord 模型