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 recordsA 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层主要追求 运行速度快。页面资源层和页面模板层主要追求 结构清晰优雅。