谈谈应用ORM框架针对遗留数据库做模型设计的一些技巧。
很多项目的开发都是基于已有数据库做开发的。遗留数据库的存在增加了java模型和数据模型之间的障碍。
很多朋友为此是否选择hibernate或者别的Jdbc wrapper的开发框架而犹豫不决。

其实，用hibernate类似的orm工具总归是明智的选择，当然不是唯一的明智的选择，我写这篇文章只是希望能够给那些还在犹豫不决的人提供一些自信的力量，可以果断的作出自己的决定。

有一个朋友询问过针对遗留系统做模型设计的问题 。很难简单回答这个问题，但是我可以提供我的一些经验，同时也把这篇帖子作为对那位朋友的一个完整的回答，希望能顾对他有所帮助。


针对统一的业务逻辑，对 业务模型，DAO/Service 分别设计精巧的的继承体系。
          很多朋友对此抱很谨慎的态度，因为他们觉得遗留系统很难有效支持业务模型的继承体系。
          他们的担心是有理的，而且通常情况下，遗留系统确实无法支持现有ORM的类继承体系。然而，遗留系统不支持，并不能阻碍我们在业务模型畅通无阻的使用类继承，达到DRY的目标。抽取出的抽象模型可以更容易实现DRY，同时这里面的业务模型的层次设计很多时候也是真正反映了“业务统一处理”的需求。
          这样的设计出现了很有意思的一个局面，业务模型是继承体系的模型，而数据模型是一对一映射的表模型，当用这种设计来处理业务的时候，特别是在处理“统一的抽象的业务逻辑”的时候，比支持继承模型的表模型 付出更多的一些努力才能达到，很多朋友一直担心这个“多付出”的努力是否会很可怕。 真的不用担心，并没有付出多少努力，你只需要在 DAO或者你的Service模块里面，做针对性的继承性的设计。通过这个合理的继承体系的DAO/Service模块，我们就可以在里面减少甚至完美弥补 因为 表模型不支持继承体系的业务模型带来的问题。

          一般来说，DAO/Service最好有这样的层次:

BaseService<----UserService,OrderService

class BaseService { update,create,delete,findById..} 

保证各个子类最终的CRUD都是通过 baseService.CRUD来完成 。

这样的DAO/Service类层次设计，为我们设计的业务模型的继承体系带来了“用武之地” ，在baseService的这个地方，大家可以把一些“需要统一处理的”业务逻辑放在此来做，比较有代表性的一点是 :

class abstract BaseService extends HibernateDAOSupport {

     public void create(Object o){
                 if(o instanceof PublishableModel){
                           publish((PublishableModel)o);
                  }
                 getHibernateTemplate().save(o);
    }

}

似乎很别扭但却很有“意义”的一段代码，PublishableModel这个抽象类代表了业务模型中某个可以统一处理的业务抽象模型，而 这段代码:

   if(o instanceof PublishableModel){
                           publish((PublishableModel)o);
                  }
 

给了这个业务模型抽象体系以真正发挥作用的“用武之地” 。


作为有经验的 开发人员，无论何时何地，都应该始终不渝的坚持并且贯彻“DRY”的宗旨。