前几日的经验之谈算是本人近些年对“简单”与“复杂”问题的一个总结。
得此总结正是缘于重温Spring所得，充分体会了解耦合之后的种种好处。
在论坛看了一些banq对Spring和EJB的精彩论述，感觉banq还是比较倾向EJB的。
本人对EJB3所知甚浅，初步接触的认识如下：EJB3是通过代码中元数据表述配置信息，与.NET很像。Spring的XML配置文件相比起来烦琐得多，但从表面看来可以对POJO进行“无侵入”的装配。
原先Rod炮轰EJB，主要的依据就是EJB与容器高耦合、远程EJB效率不佳、entity bean不成熟。现在这些问题随着EJB3的横空出世，不知有了多大的改变。
从Ioc和AOP两个设计方面看，spring与EJB3在解耦性上已经差不多了。
下面从两个发展方向来竞争：
1. 分布式 异种平台 （大公司系统有可能需要）
2. 领域模型支持 (每个系统都需要)
个人认为现在这两个框架目前对领域建模这方面支持都不够好，这是弱项，所以，才有人来捧RoR。
Spring将领域模型支持实际推给了Hibernate，而Hibernate经常被当作数据库相关技术误用，所以spring+hibernate大部分系统其实是和领域建模无关的系统，如果一个软件系统的主要业务对象都不是OO的，就是构件化组件化，也是半个残废啊。
[该贴被banq于2007年05月28日 13:08修改过]
RoR用于建模倒是好，可惜这东西为了求快，砍掉了好些层，技术环节耦合度太高了。个人理解，RoR总体上来说是就是Hibernate+WebWork，没有Spring和EJB3清晰的解耦，简化是简化了，适应性却大大降低。
而且Ruby相比Java的性能差好大一截，如果作为组件来大规模使用，只怕早晚要出大的性能问题。
个人浅见，编程语言抽象到Java、C这类的虚拟机技术层面，最好地兼容了运行速度和易用性。虽然运行速度比不上C，易用性比不过动态语言，但中庸之道适应面最广，应该还是会继续称雄，而不是像一些同道所说的没有前途。
是的，捧RoR不代表就要大规模用RoR，有敲山震虎的味道，是对java和.NET的敲打，该做的事情很多啊。
Hibernate is better employed for the product not project.
The project should use DAO to code your persistent layer.
after all, the IDE refactor functionality is still so powerful.
it is more maintenable and even the juniors can get in hand immediately.
Hibernate has serious performance side-effect in save.
if you have a lot to insert, then better to write your own sql.
due to hibernate's general feature, it decomposes one fine-tuned SQL statement into several simple sql statements to query DB.
that is a typical trade-off between general architecture and the performance issue.
for mission critical project, persistent layer loves DAO.
楼上的E文看了个大概，非常赞同。
在真实应用中，dao这个层次是万不可省的。
多数业务逻辑用ORM来表达的确比较清晰和简单。
性能要求高的地方，难免要写sql或存储过程，这样性能才有保证。
有些复杂查询，用ORM简直是自找罪受，用Spring的JdbcTemplate解决起来很快。
service这个层也不能省，否则客户端要求一变就苦不堪言。
在联机事务应用方面，客户端还是用C/S（RCP）更能让客户接受，清晰的service层可以很轻松地实现替换，或C/S、B/S并用。
而web层，像SpringMVC、Webwork这类高解耦的框架，可以根据不同需要采用不同的视图。尤其是SpringMVC，初上手太灵活、太繁琐，但精通后可以适应Web的种种复杂要求，值得深入学习。
[该贴被lgx522于2007年05月31日 08:38修改过]