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

7O/R

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

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

 

我做出这样一个lightor框架,思路借鉴了Martin Fowler的《企业架构模式》里面讲述的一些O/RRow 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能够支持这种用法。这里面,lightormapperpopulate方法需要ResultSet参数。一般的O/R不屑于这么做的,别说ResultSet,连Connection都想包装起来不给你看。

 

Lightor的设计思路也是同时应对简单和复杂。LightorMapper实体部分是自动生成代码。类似于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层主要追求 运行速度快。

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

阅读更多
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭