Java Web开发构想(5) -- 7.O/R; 8.总结

7．O/R

Hibernate, EJB Entity Bean产品，JDO产品，iBatis是比较流行的几种O/R Mapping Framework。

我做的一些工作中，经常涉及到复杂的优化过的native SQL，并且涉及到大量的批量复杂逻辑处理，现有的O/R框架都不能满足功能和性能要求。

 

我做出这样一个lightor框架，思路借鉴了Martin Fowler的《企业架构模式》里面讲述的一些O/R的Row Mapper,  Column Mapper等概念。

 

最经典的用法是：

ResultSet rs = ps.executeQuery( a long complex native sql);

//will return a lot of records

A a = new A();

B b = new B();

IMapper aMapper = MapperService.getMapper(A.class);

IMapper bMapper = MapperService.getMapper(B.class);

 

While(rs.next()){

   aMapper.populate(a, rs);

 bMapper.populate(b, rs);

 

  businessLogic(a, b);

}

 

可以看到，Lightor不需要一下子把所有纪录都放到一个Object List里面。完全可以随取随用。整个过程中，a, b只有一份，极大的节省了空间、时间，也极大的提高了开发效率，减少了重复代码。

没有任何一个其它O/R能够支持这种用法。这里面，lightor的mapper的populate方法需要ResultSet参数。一般的O/R不屑于这么做的，别说ResultSet，连Connection都想包装起来不给你看。

 

Lightor的设计思路也是同时应对简单和复杂。Lightor的Mapper实体部分是自动生成代码。类似于JDO的静态Enhance。不同的是，JDO静态Enhance直接修改bean class。而Lightor则不动原有的bean，只是多生成了对应的Mapper Source/Class。这种方式是最利于跟踪调试的。至于发布部署，和JDO的情况差不多，不如Hibernate的动态代码增强。

这里我很羡慕Python, Ruby等动态解释语言的特性，根本不需要这些麻烦事。

 

这一层我主要关注的是性能，缓存策略等等，而不是简便。我觉得，一个应用系统的瓶颈主要存在于O/R, DB层。不应该单纯为了追求OO结构的优雅，或者编程的方便，而牺牲了一些可能优化的地方。

 

关于Lightor的缓存策略, 我的Blog上有几篇文章。

http://blog.csdn.net/buaawhl

 

数据库对象的缓存策略

http://blog.csdn.net/buaawhl/archive/2004/12/21/224184.aspx

 

分页 & QueryKey & 定长预取

http://blog.csdn.net/buaawhl/archive/2005/01/08/245005.aspx

8．总结

我理想中的Web开发架构是这样的：

开发速度快，运行速度快，结构清晰优雅。

具体到每一层。

Web框架层主要追求 开发速度快。

O/R层主要追求 运行速度快。

页面资源层和页面模板层主要追求 结构清晰优雅。