我的YY：ORM的由来

考虑这么一种情况：

现有一个博客系统，用户可以写日志，可以给日志分类。

那么我们需要两张表如下：

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而已。