>与其拍拍脑袋加入对象和对象方法属性,还不如这么偏执的选择DDD
不是我偏执啊,Ruby on Rails当初诞生时打的旗帜就是Evans DDD啊,不信看看很多英文资料,作为ROR的翻版Grails如果舍本求末,忘记当初特点,不能说我偏执吧,我指出了这样一个事实本质,只是你们之前没有看到罢了。
当然,单从这点不能全部否定Grails,但是可以肯定的是,使用Grails之前必须掌握Evans DDD,这些rails兄弟就是为更好实现DDD诞生的。
个人不赞成在模型中加入find功能,那么关于save呢?在Java中我们可以使用模式来实现save,比如JiveJdon3加入的内部消息功能,当用户看完消息后,以后不再提示有新消息,也就是说,消息的内容被读取了,那么就更改消息的状态,我们可以使用观察者模式实现,如下,消息模型:
public class ToShortMessage extends ShortMessage {
public String getFilterMessageBody() { this.shortMessageState.setHasRead(true, this); return messageBody; }
}
public class ShortMessageState extends Observable{
.....
public void setHasRead(boolean hasRead, ShortMessage shortMessage) { this.shortMessage = shortMessage; if ((hasRead) && (!this.hasRead)){ this.hasRead = hasRead; setChanged();//出发 notifyObservers(this); }else this.hasRead = hasRead; }
} public class ShortMessageRepository implements Observer{ .... public void update(Observable obj,Object arg){ logger.debug(" Observable update "); ShortMessageState shortMessageState = (ShortMessageState)obj; try { this.shortMessageDao.updateShortMessate(shortMessageState.getShortMessage()); } catch (Exception e) { e.printStackTrace(); } }
}
|
getFilterMessageBody是在jsp输出消息内容时,被调用,由于ShortMessageState 的setHasRead是事件触发,导致ShortMessageRepository 的update被执行。
从这里看出:ToShortMessage 也包含了复杂的业务行为,不只是简单的Property get/Set,所以,不能认为ToShortMessage 是贫血模型,而且贫血模型也不是完全不好,特别在冬眠到关系数据库时非常简洁轻量。这又涉及另外问题,这里主要说明:不能教条主义看待失血和充血,JiveJdon3的ForumMessage粗看上去是失血,只有set/get,没有业务逻辑,但是看看其子包下MessagRender就发现业务行为不少,这些都是从FourmMessage中分离出来的,是细节设计考虑,当然如果为了面对形式上充血,我完全可以将MessageRender功能都并入ForumMessage,那谁能看得懂ForumMessage呢?OO宗旨又跑到哪里了呢?再说Evans DDD最终必须结合设计模式的。
[该贴被banq于2008-06-13 21:18修改过]