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

是啊，当年Spring刚出的时候多好，多么轻，就因为这个才用它的，现在是越来越大了，臃肿

嗯，分层和分模块之后更容易维护和开发，也能更容易理解。因为团队不是你一个人，那是很多人在协同开发。

最近看了jbpm4。
感觉比较靠近ddd。
而且相对来说，jbpm4中service和entity职责划分挺好。
jbpm4整个又是大量使用了命令模式，使得service很简单，真的成为一个单纯的对外接口。
总之jbpm4的参考价值还是很大的。

一种是事务角本模式（Transaction script）


应该是事务脚本吧

为什么总想着绕开“SQL”——SQL有那么不好么。。。

刚看了下那个roo自动生成的那么一堆findBy方法，疯了——还比如自己写个动态sql生成的简单（起码只有一个方法），字段变了还要重新生成？

基于数据库的应用本来就没那么多事儿，业务复杂了，也不用把和数据库交互这块弄得这么深——很多情况下，只用SQL，简单的事务，kiss啊

当我们用hibernate这些orm东西的时候，我们已然在避开sql.这个没什么好说的。如果只是简单的crud操作，用hibernate还是非常能提高各方面效率的。当然复杂的业务，hibernate也能做，前提是把hibernate用好了。但实在太复杂的时候，简单的sql确实比较高效，这方面直接spring的模板就完事。很多的情况下，crud占了80-90%以上，这样注定了hibernate的流行。

Ibatis Spring JdbcTemplate都在5年前用过，虽然项目小，但开发过程一样没见得简化多少，而hibernate的entity对象，不管是xml还是annotation，个人感觉在贫血的情况下甚至没有出现在项目中的必要——每一层都可以以coc的形式约定就好，一直到数据库表，1:m m:m也没那么复杂。 顺便问下使用hibernate的童鞋，假设一个数据库表的设计合理，有50-100个字段，做一个增删改查，是不是也要写一个庞大的bean？

你这是纯属抬杠。哈哈。你怎么不说500个字段呢？在我们做过的大多数项目里，哪有出现那么多字段的。你这是拿特例来说事。特例自然有特例的处理方法。比如一些报表系统，有很多字段的。可以事前统计，做物化视图等。对于海量的数据，自然有相应的处理技术。这些都不是hibernate擅长的地方，也就是剩下那10%左右不能做的事情。

1000W行，代码写的多好像也不能说明什么问题，用不用OO和能否写出好软件没什么必然联系吧~~~

有些人以为拿出面向对象就可以反驳了？这岂不是很好笑的事情，好与不好是结果评价，怎么成了手段评价。一个产品没有宣称面向对象，但是千万人使用，一个产品宣称面向对象，但是无人问津。谁成功谁失败一目了然，难道还有说人你的东西不符合面向对象，所以我的东西好，这不是扯淡是什么。