Hibernate3.0 vs Rails Active Record

    前篇：最美的MVC,ORM方案原来在别处--Ruby on Rails    

    Rails的出现，良性的冲击了自己目前使用的Spring+Hibernate架构。有冲击是好的，否则EJB2和Struts现在还一统江湖。
    本文主要记述了Hibernate3.0(H3)和Rails Active Record(AR)在定义和使用Domain Objectt方面的优劣，更重要是冲击过后，计划如何重构改善自己的框架。

POJO定义
1.AR定义POJO的只需这样寥寥几笔

class Company < ActiveRecord::Base
   has_many   :clients
   belongs_to :boss
end

其中"公司名"之类的属性，已经被Automate Mapping了，而has_many、belongs_to语句清晰的声明了与clients、boss的关联关系。

2.对比Hibernate2.0时代
程序员必须同时维护POJO与hbm两个文件事无大小逐一重复声明，而且如果使用XDoclet，更加冗长得要命。此时，Active Record的定义方式简直是生产力大解放，两家的代码行数上有几十倍的差别。

3.幸亏，Hibernate3.0已经支持Annotation声明。
终于可以丢弃hbm文件了，同时h3也会拥有表名和列名auto mapping的智能，就像这样：

@Entity
public class Company implements Serializable
{
    @Id
    public Long getCompanyNo() { return companyNo; }
   
    public String getName() {return name;}
   
    @ManyToOne
    @JoinColumn(name = “boss_id”)
   
    public Boss getBoss() {return regionalCenter;}
    
    @Transient
    String getLengthInMeter()
}

其中公司名被automate mapping了， @ManyToOne定义了关系，@Transient定义了该属性不需要被持久化。

4.最后觉得
对比起来，似乎Hibernate3.0 的方式更好，毕竟AR把东西都列名都auto-map得没影了，要自己打开数据库的Schema来看。而且H3可以比AR定义复杂的关系和情况。不过H3的Annotation只出到Beta1，还要赶紧努力。

Domain Model使用
首先两者都属于Martin Fowler说的Domain Model范畴，不过AR当然就是Active Record模式，而Hibernate属于Data Mapper。

Active Record因为totally只有一个POJO对象，所以几乎强迫性的使用了DDD的模式。
而Data Mapper模式据Martin说为了彻底解耦数据库结构和领域对象，增加了一个EntityManager类( JDO 叫PersistenceManager, Hibernate 叫 Session. TopLink 叫 UnitOfWork)，这便引发了关于DDD(Domain Driven Develope)和贫血的POJO，事务脚本式的Service层等无穷争论。

Active Record的特点：代表着数据库中的一行数据，拥有领域对象的领域属性，领域方法和持久性方法，finder方法被定义为类的静态方法。同时因为Cat继承于ActiveRecord，因此默认具有new,save,find,find_all等方法。

cat = Cat.find(pkId)
cat.catch(mouse)
cat.save

对于极端OO分子及小白编程主义者来说，上面的代码真是棒极了。

而Hibernate里面，因为有session，有Manager类，还有Service层，甚至还有一个DAO层的存在，组合便变得迷离起来。

争论的起因很简单，因为领域方法在极端理想的情况下才会只操作自己的属性，比如countTax()，而很多情况下都需要动态的执行find()方法从数据库里再拉些对象参与事务，有很多时候拉的还是别人的对象。因此，怎么组合Service,Manager,DAO变是DDD争论的开始。

关于DDD的口水已经太多了，自己实际中也还是高级DAO的水平。这里随便一说：


1.有些极端清廉的做法：
　每个Manager只负责与自己的POJO相关的动作，把综合的事务都交给Service层，这就是让Martin大发牢骚的复杂service模式。 
    其实这是把Manager类重新退化为表入口的模式。既然我们提倡OO，就应该勇敢的进行关联，从来没见过不关联别人的事物。怕的话最多把依赖对象抽象成一个interface。依赖一个很公共的interface比依赖某个具体实现类强。

2.另一个最普遍的清廉做法：
　POJO就only拥有自己的领域属性，和领域方法，而没有DAO的句柄。这种模式，即使是很多示范性的著名例子都是这样的。其实如前所述，这显然一厢情愿的认为领域方法就是倒腾领域对象自己的那几个属性和相关对象，POJO持有DAO的指针是需要的。
    所以POJO应该利用Spring，利用IOC，很优雅的在必要时持有DAO和他的session，很希望有著名例子能够提供这样的示范。

３.在Rod的<withdout EJB>里，是这样子折中的：

public class OrderManager 
{
　private OrderDao orderDao;
　public void placeOrder(Order order) 
　{
　　orderDao.storeOrder(order);
　　orderDao.updateInventory(order);
　}
}(摘自<withdout EJB>例子)

 大家看到了什么？
1.商业方法和持久化方法没有严格区分，都混在orderDAO里，商业操作里可以带有持久化方法．
2.OrderDAO有执行对Order以外的对象（库存对象）的操作．
3.商业对象是Manager对象，而不是POJO对象--order对象，所谓POJO应该依旧贫血，戏份不大．（让POJO持有DAO句柄在Spring里不太容易）

可以看出Rod非常非常非常的实际．
Rod说，当有别的持久化方案袭来，或者自己想要把代码弄清晰点的时候，才需要把Data Acess Object和Business Object分开．

改进计划

1.首先是尝试使用Hibernate3.0 Annotation Beta1，去掉hbm文件，并使用她的automapping功能简化配置

2.使用反射，加强Manager类的父类，拥有一批默认的方法。
    虽然有MDA可以自动在子类生成这些方法，但我认为生成以后还是有维护与代码量的成本，所以即使是Code Generation，也应该先使用重用技术把代码减到最少再进行代码生成，不能因为有了Code Generation就不注意代码的抽象重用。

3.研究如何在Spring体系下让POJO优雅的持有DAO句柄，实现真正的DDD编程。
　当然也可以不干这个，继续Rod的实际模式．

4.参照Rails , 研究如何在父类增加validates_uniqueness_of   :subdomain这样的函数。

5.参照Rails , 研究Hibernate3下面对Event的管理和Observer模式的应用。

最后, TSS上有个Hibernate vs Rails的文章,是由<Hibernate Quickly>的合著者写的。