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

也许不会看见 2010-03-25

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

昨天实践了一下SpringRoo,给我的感受不亚于两年前第一次实践Rails的快感。但在网上及论坛上搜了一下对SpringRoo的分析,发现文章不是很多(可能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也是GavinKing大牛的另一大作,但是因其前端标配JSF等因素使得它并没想Hibernate那样流行。虽说Seams在基于JEE标准上使得Java的领域模型做的非常好了,但是它仍旧延续EJB的开发模式,让业务逻辑封装在SessionBean中,而数据则仍然是Entity的主要责任,所以说感觉并不是一个真实的充血模型。

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

相关推荐