PEAA : Patterns Of Enterprise Application Arc…

2008-02-23 10:14:55来源:互联网 阅读 ()

新老客户大回馈,云服务器低至5折

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
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:Tomcat5数据源配置--tomcat笔记2

下一篇:jsp连接数据库---Mysql