PEAA : Patterns Of Enterprise Application Arc…

1, 事务脚本 vs. 领域模型（Transaction Script vs. Domain Model）

作者基于功能的复杂性来区分两种模式的使用时机，却忽略了另外一个因素：功能的增加

领域模型将功能和数据置于同一个对象中，当需要增加新的功能时，只能通过为对象增加新的方法来实现，这造成了对象接口的不稳定，并无法在没有源代码的情况下进行功能增加

而事务脚本则可以灵活的进行功能的扩展：增加一个Command Handler子类，配置到系统中即可，不需要改变对象接口，不需要修改源代码

进一步，可以使用Visitor模式将领域模型和事务脚本粘合起来：核心或常用功能用领域模型建模，可以使用子类化消除复杂的逻辑判断，而预留一个accept（visitor）接口来支持功能的扩展

总之，当数据变化不大，而功能经常增加时（不是同一个功能逻辑复杂性增加，而是新功能的增加），事务脚本配合Command模式理论上拥有更好的扩展性

2，表模块（Table Module）

是“管理者（Manager）”模式的变种，管理的不是通用的内存对象，而是“实际的或虚拟的表，及其中的行”，可用于隐藏数据层，甚至根据表之间的关系，可以建立一个Table Module的继承层次

3，服务层（Service Layer）

初看到名字时，还以为基本是和“EntERPrise.Solution.Patterns.Using.Microsoft.Dot.net”中的“Service Interface”类似的模式，细看之下，发现正是最近想求证的一个模式，因为在自己的项目中混合使用了事务脚本和领域模型（前面1，事务脚本 vs. 领域模型中提到的问题和最终的方案，正是目前自己项目中的问题和方案），一直感觉不是很纯粹的设计，现在发现，目前的设计基本类似Service layer，只需要再明确划分一下“领域逻辑”和“应用逻辑”即可

(to be continue...)

上一篇： tomcat5连接池配置
下一篇： JBoss3.x和4.x下配SqlServer JDBC驱动

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有