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层主要追求 运行速度快。
页面资源层和页面模板层主要追求 结构清晰优雅。
发表于 @ 2005年05月31日 08:37:00|评论(loading...)|编辑