实现Java语言的领域模型，比较看好Spring Roo

首先说一下这篇文章的目的是想就最近新发布的Spring Roo再谈一下Java语言的领域模型开发，只是发表我对Roo尝试的第一感觉，欢迎大家讨论。

昨天实践了一下Spring Roo，给我的感受不亚于两年前第一次实践Rails的快感。但在网上及论坛上搜了一下对Spring Roo的分析，发现文章不是很多（可能Roo发布时间还不很长）、评价也不是很高，有说Roo只不过是剥离了Groovy的Grails。但就我个人感觉，首先Roo是基于Java语言的（正如Rails基于Ruby和Grails基于Groovy语言一样），但Java特性远不如动态语言Ruby和Groovy灵活。缘于Java是目前企业应用开发的第一语言，多数有着广泛Java基础的公司弃Java选Ruby或Groovy是比较困难的，Hibernate+Spring则在近些年成为企业开发的主流。但是对于基于Spring框架的贫血模型经常被大家所诟病，而就我个人的经验，最近一个基于Spring+Hibernate的项目也让我开始厌恶这种贫血的Service+Dao开发模式。

看了一年前关于Java充血模型的困难，主要难点就是Java语言无法做到像Ruby的mixin和C#的partial等语言特性，另外当时Spring的AspectJ织入还不够强大。但是如今Roo发布以后却让我感觉SpringSource在这方面已经做得非常好了，首先能像rails和grails的代码生成(Tab提示则更为智能)、基于Annotation和AspectJ编译时的织入，很好的将ActiveRecord模式的引入到POJO中(但属于不同编译单元，POJO除了多几个Annotation就只剩field了，连setter/getter也可以通过Annotation在编译时织入)，这样很容易使得Entity更加关心属于自身的业务逻辑，因此Service层不再是必要的(需要事物/安全边界或其它目的时选用)，DAO层则根本不再建议使用了。

顺便比较一下去年了解的Seams，Seams也是Gavin King大牛的另一大作，但是因其前端标配JSF等因素使得它并没想Hibernate那样流行。虽说Seams在基于JEE标准上使得Java的领域模型做的非常好了，但是它仍旧延续EJB的开发模式，让业务逻辑封装在Session Bean中，而数据则仍然是Entity的主要责任，所以说感觉并不是一个真实的充血模型。

回到Spring Roo，虽然Roo功能目前还不很强大，比如还不能根据配置的数据库链接直接从数据库表来生成Entity，以及前端表示层使用JSP和绑定Spring MVC(基于Spring 3.0支持REST)等，但是这些改进目标已经纳入其roadmap中，毕竟Roo才发布两三个版本，因此个人还是比较看好它的:)