ORM如何用才不是滥用
因为web 应用每一次处理都要响应一个数据库操作，添加，修改，或者删除，所以关联集合对象的取出不是必要的
ORM自动取出对象，自动发现变化，自动保存也许只有在桌面程序或者有状态的web应用，例如jsf中才有意义，而且必须不是open session in view模式.否则操作中会存在大量的取出对象，修改对象，然后再保存回去的操作。
所以为了让每一次click中db操作最少，必须对DAO进行细力度的封装
以petstore中order对象的装载为例，其中要用到一个lineitems的集合
public Order getOrder(int orderId) {
Order order = null;
Object parameterObject = new Integer(orderId);
order = (Order) queryForObject("getOrder", parameterObject);
order.setLineItems(queryForList("getLineItemsByOrderId", new Integer(order.getOrderId())));
return order;
}
在DAO里面，把关联分成两步来填充。
对于一个完全domain设计的系统中，对象的集合属性的对象中可能存在大量的级联的关联
完全用lazy load不是一个好方法，无论从代码上，还是从性能上。
所以可以说ORM在设计之出就没有给出一个对于orm自身的设计模式的说明
例如Order->LineItem->Item->Product->Category->ParentCategory，
这样我持久一个order，该需要多少个操作呢
尤其在web这种stateless的环境中
对于一个最简单的student-sc-class,三张表，如果要把一个学生和一门课关联起来，只要在DAO里面，SetStuClass(stu_id,cls_id)就可以了，如果用ORM来做,s需要先load一个student对象，然后stu.addClass(class),然后session.save(stu),这样还真是kinda weird
=======
所以对于orm操作模式化这个问题，首先要把写和读操作分开来看
对于读：也就是查询，
如果结果仅仅是某个对象，且附属表的信息可以作为该对象的集合
例如employee-1:n-employeecontract,可以采用ORM或者DAO，甚至ORM在这里更方便
如果结果需要的字段跨多个表，结果集可以用map来存放
例如 unit-1:n-employeecontract-n:1-employee ,现在要显示某单位所有的employeecontract为一个列表，那么可能三个表各需要几个字段，此时就不应该使用ORM，而用List<Map>来存放
对于写：
例如在employee-1:n-employeecontract中保存一张employeecontract，完全没必要使用employee的集合来保存，但是如果一旦定义了employee和employeecontract,这里就必须使用ORM来保存，否则employeecontract就是一个emptylist,所以，上面的第一条还是应该使用DAO来保存
所以，以上就说明了一点，在必须有pojo这样domain object的实际应用中，ORM并不可行，细力度的DAO才是一个更好的方案，但是我们还需要一个工具，能将pojo中需要的元素自动映射到表里面
当然，hibernate可以做这样的工具，不过要吧字段以xml或annotation的方式声明出来，ibatis也可以做，不过映射文件也太过于复杂了
其实只是需要一个像php的adodb这样的工具，不过必须使用对象，主要是处理对象变量填充和变量类型转换，而这两个过程在php中是不需要的
反正hibernate是肯定要用的，关键是怎么用才不是滥用
hibernate3也对SQL有很好的支持支持
sess.createSQLQuery("SELECT * FROM CATS").list();
sess.createSQLQuery("SELECT ID, NAME, BIRTHDATE FROM CATS").list();
sess.createSQLQuery("SELECT * FROM CATS").addEntity(Cat.class);
sess.createSQLQuery("SELECT ID, NAME, BIRTHDATE FROM CATS").addEntity(Cat.class);
所以hibernate最佳实践可以归结为：
更新还是以表为单位手动更新，读也是以表或视图为单位，对于关联的集合，手动加载
发表于 @ 2007年02月12日 17:12:00|评论(loading...)|编辑