命令和查询责任分离(CQRS)架构模式
http://simpleframework.net/blog/v/5525.html
贫血的域模型(Anemic Domain Model)
构建贫血的领域模型并无什么不妥,但对于较为复杂的业务逻辑应用,它可能不是最好的选择
最终结果只能是代码间高耦合的很多“意大利面条式的代码”
贫血的领域模型使得其业务逻辑遍布整个代码,如果业务规则改变,需要经常更新多个地方的代码
可以以一个简单的业务场景,或代码来展现一下
什么是 贫血的域模型,什么是 富领域模型 吗
用了 贫血的领域模型,哪些代码间会 高耦合很多“意大利面条式的代码”
典型的富领域模型将所有业务逻辑隐藏在模型内部,而大多数对象间相互关联。试图构建一个完美的模型来解决领域的业务逻辑,这往往是以此方式开发软件失败之所在,其结果是一个非常庞大的模型,而应该考虑有限的上下文
而 富领域模型,应该考虑有限的上下文 指的是什么
贫血 大概就是 bean中只有字段。 dao.save(bean) manager.validate(bean).
富大概就是bean bean.saveOrUpdate() bean.validate()
当年javaeye上有主题讨论的
http://www.iteye.com/topic/11712
这个是robbin当时的帖子
http://www.iteye.com/topic/283668
这个是2个简单的充血、贫血的例子
确实需要补
很多东西 几年前看的 和几年后看的
理解层次不一样的
明白了2楼所说的
其中一点就是 富的,BEAN 也做了VALIDATE 之类工作
Torque、EJB 2.x 的 Entity Bean 就是一种富领域模型,也有称为充血模型的。充血模型中除了包含 set/get 之外,还包含了连接管理、事务管理等一系列的东西。
像 Hibernate, JPA 等则是贫血模型,领域实体中除了 set/get 之外,几乎没有其他东西了,贫血模型也称为 POJO 模型。