考虑这么一种情况:
现有一个博客系统,用户可以写日志,可以给日志分类。
那么我们需要两张表如下:
T_BLOG
=========
id
classId
title
content
publishTime
T_BLOG_CLASS
=========
id
className
如果用传统的JDBC编码,PO应该是这么设计的
public class BlogPO{
private String id;
private String blogClassId;
private String title;
private String content;
private Date publishTime;
//setter & getter
}
public class BlogClassPO{
private String id;
private String className;
//getter & setter
}
假设现在我们需要在页面显示日志列表及其分类的名称,我们的DAO中就需要一个查询的方法返回一个List<BlogPO>,但是BlogPO没有className这个成员,如何显示className呢?难道再去数据库查询一次?这方法显然不太可取。于是有人想到了VO,创建一个和页面表单对应的VO,然后DAO里的这个查询方法用联接查询返回一个List<VO>,这样只需要一次查询,就能得到页面需要的数据,问题似乎解决了。
时间一久,项目慢慢变得庞大,页面越来越多,成堆的VO等着我们去维护,维护成本越来越高,于是有人开始寻找另外的解决方法,
有人想到把BlogPO设计成这样:
public class BlogPO{
private String id;
private BlogClassPO blogClass;
private String title;
private String content;
private Date publishTime;
//setter & getter
}
DAO的查询方法直接返回一个List<BlogPO>,需要className时,可以调用BlogPO.getBlogClass().getclassName()。于是ORM诞生了。
最初的ORM是在加载BlogPO时自动加载BlogClassPO的,后来遇到BlogPO里有些成员是个集合(比如Set)或者是个Blob/Clob字段的情
况,在不必要加载时候自动加载它会增加很多开销,于是出现了“延迟加载”技术。再后来…………
自动生成SQL语句我觉得倒是次要的,ORM和传统的JDBC编程最本质的区别是:BlogPO里应该持有一个BlogClassPO成员还是一个
String blogClassId成员。
上面只是我的猜想,只是今天自己在写blog,不用hibernate而用jdbc来写,遇到这么个问题,然后想了这么多,突然觉得自己明白
了ORM的用处。呵呵,YY而已。