Domain Object贫血vs富血(DDD)和spring roo到ruby的扯淡

书是好书，看过也不能代表什么。如果DDD，真的是银弹，我相信肯定早就流行了。它不流行，必要有它的缺点和局限性。

说一下另一个框架Seam对于富血也做得不错了，但还不是完全富血，同样也绑带了JSF。

看不下去了，我来简单地告诉你们什么是ddd。具体的去jdon看看。
ddd就是利用ORM和AOP屏蔽数据库的sql和事务。比如
bool login（userid,password）;
{
User user = repository.get(User.class,userid);
return user.checkpassword(password);
}
而不是select * from users where userid=? and password=?
比如学生选课
student.addClass(class){this.classes.put(class);}
repository.update(student);//此处级联更新新增的class
而不是insert into classes values(....)

总之，这种代码几乎看不到sql，看不到commit，仿佛一切都在内存的集合里。hibernate的session基本上直接拿来当repository用就好了。

但显然DDD有其适合场景，有些时候性能成为大问题，必须用hql,甚至sql等办法来解决。

领域模型只是一种思路，为什么没有流行起来是因为没有真正能够支持领域模型的充血Domain Object框架存在，Rails靠近了这个思路。由于java死板的语法的原因，在java中实现Domain Object，现在来说还不现实。除非再出现一个类似Hibernate那样划时代的Domain Object ORM框架出来。

另外：
Spring Roo只适合做DEMO，或者说是一种前进道路上的不成功的尝试，真实的业务问题使用Spring Roo是不行的。

又另外：
我们自己也做了一个java充血模型框架，可以说的是比Spring Roo要好一些。但是依然解决不了领域模型框架的问题，可以说纯领域模型框架在现阶段是不存在的。

我又上来骂一句，呵呵。

当年整出什么Core J2EE设计模式，VO，DAO，Service，Facade出现了，当时人们眼前一亮，我靠，原来世界上面可以把层次分析得怎么清晰。后来，随着项目的扩大，又不行了。又跳出来骂，妈的，搞这么多测试，DAO都搞个接口，一大堆Service，Manager在里面。老子还不如搞一个Util类去处理。这个时候，又反思为什么太多的DO或者VO作为贫血对象，我习惯成为Thin Object,而相反为Rich Object。

我记得一次和某CTO分析系统时，我提出JSF和EJB的方案，被他批评了，他认为层次华清晰地MVC是一个银弹，我对他说确实很“淫——荡”。

很多系统架构师很容易被洗脑，很少去看非主流技术。

说到整体，有状态的EJB不正是干Rich Object的吗，有人说性能不好怎么低，复杂，都是瞎扯。首先，看看业务和开发效率，难道Rich就不能OOP吗？只要是Java对象都能OOP，只代码风格和关注点不同。

对不起，我又冲动了！

那你Rich了吗？你们的团队Rich了吗？说实话，我们现在的团队，还是老一套，走主流的一套。是Web应用.
web层-vo(将来可能rmi or hessian)-spring-po-dao-hibernate.今天讨论还有个小弟提出0配置和无vo、无接口方式,他说我们是为了接口而接口。哈哈。结果当然是部门经理主流派战胜，有权嘛。我做为夹心层，只能分析各自的优缺点，然后稍偏向小弟。但是说了一句：各有优缺点，这个由老大拍板。但其实thin的也挺好的。

说到整体，有状态的EJB不正是干Rich Object的吗，有人说性能不好怎么低，复杂，都是瞎扯。首先，看看业务和开发效率，难道Rich就不能OOP吗？只要是Java对象都能OOP，只代码风格和关注点不同。

官大一级压人呀！多元化的思想，很难形成规模！