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

您所在的位置：程序员俱乐部 > 编程开发 > Ruby > Domain Object贫血vs富血(DDD)和spring roo到ruby的扯淡

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

2012/3/23 23:50:51 peterwei 程序员俱乐部我要评论(0)

摘要：引子：前几天，小胖和我说他们公司CTO批他了，说他写的代码不够OO，不够DDD。细问才知道他们CTO在推DDD(领域模型驱动设计).我当时给他的观点是，JavaEE应用是天生贫血的，并不能像ruby之类的语言做到很好的富血，做到DDD。因为这些观点也是N年前讨论过的问题，我记得冒似robbin当年还下过定论：Java天生是贫血的。所以有了ruby之流做RAD快速开发。但当seam到springroo的出现与完善，富血DDD在Java里也变得可行起来（此论言之尚早，拭目以待）
标签：Ruby Spring

引子：
前几天，小胖和我说他们公司CTO批他了，说他写的代码不够OO，不够DDD。细问才知道他们CTO在推DDD(领域模型驱动设计).我当时给他的观点是，JavaEE应用是天生贫血的，并不能像ruby之类的语言做到很好的富血，做到DDD。因为这些观点也是N年前讨论过的问题，我记得冒似robbin当年还下过定论：Java天生是贫血的。所以有了ruby之流做RAD快速开发。但当seam到spring roo的出现与完善，富血DDD在Java里也变得可行起来（此论言之尚早，拭目以待）。我以前也和别人争吵过哪个更好，现在我的思想又受到了一些冲击，你呢？世界在发展，我们的思想是不是也应该与时俱进呢？

贫血vs富血

我们来回顾一下。在企业架构模式中，业务层的实现一般有两种模式：一种是事务角本模式（Transaction script），另一种是领域模型模式（Domain Model）。这两种分别对应贫血和富血。好吧，我们不说这些扯淡的东西，我们简单点说。

所谓贫血，就是一个对象里只有属性，如java中的pojo，要实现业务，要依靠service层来实现相关方法，service层的实现是面向过程的，也就是所谓的transaction script.我们现在大量的分层应用action->service->dao->entity的方式就是这种贫血的模式实现。

//贫血代码示例：
Account.java
Public class Account{
	private String name;
	private Long num;
    get set…

}

AccountService.java
Public class AccountService{
	public List findAccountBySomething(String abc){}
	public void addAccount(Account a){}
	public void  otherBiz(){}

}

所谓的富血就是属性和方法都封装在Domain Object里，所有业务都直接操作Domain Object。Service层只是完成一些简单的事务之类的，甚至可以不用service层。也就是直接从action->entity.

//富血代码示例
Account.ava
Public class Account{
	private String name;
	private Long num;

	public List findAccountBySomething(String abc){}
	public void addAccount(Account a){}
	public void  otherBiz(){}
}

前人总结的一些贫血和富血的对比：
贫血模型的优点：
1.被许多程序员所掌握，许多教材采用的是这种模型，对于初学者，这种模型很自然，甚至被很多人认为是java中最正统的模型。
2.它非常简单，对于并不复杂的业务(转帐业务)，它工作得很好，开发起来非常迅速。它似乎也不需要对领域的充分了解，只要给出要实现功能的每一个步骤，就能实现它。
3.事务边界相当清楚，一般来说service的每个方法都可以看成一个事务，因为通常Service的每个方法对应着一个用例。
其缺点为也是很明显的：
1.所有的业务都在service中处理，当业越来越复杂时，service会变得越来越庞大，最终难以理解和维护。
2.将所有的业务放在无状态的service中实际上是一个过程化的设计，它在组织复杂的业务存在天然的劣势，随着业务的复杂，业务会在service中多个方法间重复。
3.当添加一个新的UI时，很多业务逻辑得重新写。例如，当要提供Web Service的接口时，原先为Web界面提供的service就很难重用，导致重复的业务逻辑（在贫血模型的分层图中可以看得更清楚），如何保持业务逻辑一致是很大的挑战。

富血的优点是：
1.领域模型采用OO设计，通过将职责分配到相应的模型对象或Service，可以很好的组织业务逻辑，当业务变得复杂时，领域模型显出巨大的优势。
2.当需要多个UI接口时，领域模型可以重用，并且业务逻辑只在领域层中出现，这使得很容易对多个UI接口保持业务逻辑的一致(从领域模型的分层图可以看得更清楚)。
富血的缺点是：
1.对程序员的要求较高，初学者对这种将职责分配到多个协作对象中的方式感到极不适应。
2.领域驱动建模要求对领域模型完整而透彻的了解，只给出一个用例的实现步骤是无法得到领域模型的，这需要和领域专家的充分讨论。错误的领域模型对项目的危害非常之大，而实现一个好的领域模型非常困难。
3.对于简单的软件，使用领域模型，显得有些杀鸡用牛刀了。
4.对于事务等的处理，如果完全DDD,java支持得不够好。

关于Spring roo
引子中小胖公司就是采用Roo完成DDD富血开发。Spring Roo is a popular open-source rapid application development (RAD) tool for Java developers. ，使用命令行或工具操作来生成自动化项目，操作非常类似于rails。Roo可以很好的支持富血的Java DDD。关于roo我也不想说太多，因为我也没有亲自实战过，大家可以google一下。

如果采用roo,只需要
对于一个业务实现

@Entity  
@RooEntity  
@RooJavaBean  
@RooToString  
public class Employee {   
    @NotNull  
    @Size(max = 200)   
    private String name;   
  
    @Temporal(TemporalType.TIMESTAMP)   
    private Date birth;   
}  

//EmployeeController代码如下： 
@RooWebScaffold(automaticallyMaintainView = true, formBackingObject = Employee.class)   
@RequestMapping("/employee/**")   
@Controller  
public class EmployeeController {   
}

在这里出现了一行@RooWebScaffold注解，做过rails的人会想，这不是rails里面的scaffold吗？没错，通过@RooWebScaffold注解，EmployeeController自动获得了curd的所有功能。

好了，就这么简单，一个domain，一个Controller，我们就可以发布到tomcat中运行了。

引用Roo功能目前还不很强大，比如还不能根据配置的数据库链接直接从数据库表来生成Entity，以及前端表示层使用JSP和绑定Spring MVC(基于Spring 3.0支持REST)等，但是这些改进目标已经纳入其roadmap中。说一下另一个框架Seam对于富血也做得不错了，但还不是完全富血，同样也绑带了JSF。
这两天又看了一下spring roo,修正一下观点，新的spring roo版本已经可以用DBRE reverse from db.并且好像也很强大。

1.一个entity只需要写属性就行，get set免。
2.简单的增删改查功能，一键生成。
3.通过aspectJ实现编译时aop，完全不影响性能。
4.可以动态查询：如findPersonByNameAndMinMax(),相当于like name,between min to max这样的功能。
5.用Spring roo实现DDD，只有两层Controller层和Entity层。另外Service层（可选），Dao不推荐用了。
6.jms,email,json序列化支持
7.其它说明：开发需要JDK1.6以上。
8.不想用roo时，可以快速删除annotation和相关的jar包等文件。
...

Spring roo架构overview：

AspectJ实现编译时AOP

自动动态查询，自动生成

想了解更多roo内容，可以看看此文：使用Spring Roo ，感受ROR式的开发
http://www.iteye.com/topic/443059
还有看官方文档：
http://www.springsource.org/roo

关于ruby
Ruby我没有使用过，只是有所了解。所以不敢评价。但是当spring roo等框架成熟起来后，java语言就能很好的支持富血，更好的OO，更好的DDD，也能支持web快速开发了。那么我们能不能斗胆问一句：基于Java的开发者，想实现ror一样的web开发，还需要ruby吗？我们没必要向ruby转了吧？

小结：
我们对于新的东西，总是会有一种天生的阻抗性。就如我习惯了贫血的开发模式，有了更OO的spring roo出现时，我内心里还是不大看好它。正如前些天一些人说spring越来越庞大，不好一样，我想他们也是内心的阻抗性在起作用。但一个人要有一个更高的视野，时刻准备一些东西，当风暴来临时，可以从容面对。

ps:说一下我的观点：
我是多年的贫血模型的实践者，基本上并没什么特别觉得不适的地方，虽然贫血模型不那么OO。其实我对于这个spring roo并不是特别看好。但是需要去了解它，和关注它。(可能又要修正了，看发展情况吧)

国外有一篇文章对spring roo的观点，我是比较赞同的:
When to use Spring roo?
http://java.dzone.com/articles/when-use-spring-roo?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+javalobby%2Ffrontpage+(Javalobby+%2F+Java+Zone)
我抽出几个重要的出来：
What is Spring Roo?
“Spring Roo is a lightweight developer tool that makes it fast and easy to deliver instant results. Best of all, you code 100% in Java and get to reuse all your existing Java knowledge, skills and experience.

Spring Roo is awesome for CRUD-Clients!

Spring Roo is good for learning Technologies!

Spring Roo is NOT good for complex Projects (yet)...

Conclusion: Spring Roo is a nice Tool => Become a Part of the Community!
My final conclusion: You should know Spring Roo, because it is nice, but you should also know when to use it and when to use something else. Use it to create CRUD applications or to learn technologies. Do not use it (yet) for complex, large projects.

基本上结论就是，你必需知道spring roo,因为它确实很好，但是你必需知道什么时候使用它，什么时候使用其它的开发方式。用它来生成简单的，业务不复杂的crud应用，或者只是用来学习新技术。不要使用spring roo来做复杂的，大型的项目。

别人的一些观点：
1.Martin Flowler批贫血的文章：AnemicDomainModel
http://martinfowler.com/bliki/AnemicDomainModel.html

也许在现有的技术和框架支持下，Java的DDD和富血应用已经开始成熟。ruby是否可在java界休止了呢？等待先行实践者分享经验。

欢迎拍砖，谢绝谩骂！

附件为:spring roo快速学习文档

springroo快速学习.rar (1.2 MB)
下载次数: 303