大音希声、大象无形

Java企业级应用软件开发探讨

JavaEE持久层开发方式现状和简单评价

基于JavaEE的分布式三层企业级应用的数据存取方式有很多种,比如关系型数据库、普通文件、远程服务等。但是数据的存取主要采用关系型数据库,下面主要关注关系型数据库的持久层开发方式。

开发方式大体以下几种方式(括号内为目前使用它的工作难度、强度,记住,我们讨论的是动辄就上百个表、几个业务小组联合开发的企业级应用,所以工作强度的估计一点儿也没有夸张):
  1. 直接JDBC操作(简单,小):底层操作(注1)较多,弄不好就会造成业务逻辑层和持久层的高度耦合。
  2. SQLMapping(比较简单,一般):把底层操作全部提取出来统一进行管理,本身并没有对概念上进行什么革新。但是这种统一的处理在逻辑上其实属于分而治之的逻辑,通过良好的对它的使用可以体现出松耦合实现持久层的要求,也相对比较便于管理和修改。
  3. O/RMapping(有学习曲线,没有工具支持会相当大):存在的时间已经很长,我认为它的最主要的作用是关系型数据库的反设计——关系型数据库的设计 就是要把现实中的对象和对象间关系设计成实体和实体间的关系映射。而O/RMapping恰好相反,它是把实体和实体间的关系映射还原回对象和对象间的关 系。
  4. Entity EJB(有学习曲线,没有工具支持会相当大):我没有对它进行过深入的研究,但是从J2EE的概念上看,它是属于O/RMapping概念的一种。它既是 一个事实上的工业标准而且又体现了EJB的容器管理特性。本身其实是很值得研究的,但是由于目前而言EJB3.0刚刚起步,而EJB2.0的开发也确实比 较麻烦,还有等等等等一系列的其他事情,我对它暂时处于观望态度。
  5. DataSet(比较简单,看实现方式):这是所有从PB和C++Builder年代走过来的人最喜欢的方式,它并没有对关系操作进行对象封装,但是它却 在对象级别对数据库的操作进行了比较好的封装,相对而言它的使用难度跟SQLMapping 相当,但是工作强度却比SQLMapping要低。目前IBM和BEA提出那个CommonJ的持久层操作Service Data Objects没用过,不提什么意见,但是MS.NET的ADO.NET倒是用它做过项目,有点了解。MS的ADO.NET主要是通过DataSet经由 DataAdapter进行数据持久化操作,由DataSet记录每一次对它的数据操作,在重新得到数据库连接后,会经由DataAdaptor通过分析 元信息(一般也是映射)和数据操作记录来自动生成该执行的SQL语句。DataSet本身可以跟XMLSchema等同(两者可以相互转化),所以在表现 XML数据的方面它是当仁不让的。我认为DataSet的机制是ADO.NET的核心机制,也是微软在应用开发方面策略的所在。

评价:

不用说也能清楚,直接JDBC操作的方式持久层和业务逻辑层耦合最严重,只要持久层有一点改变,业务逻辑层就得相应的改变重新打包和部署,反之亦 然。事实上一个超过300个Class文件和500个JSP的中等项目中遍布JDBC直接操作的话,数据库库表和业务逻辑的每一处小的修改都是一场噩梦。

SQLMapping还算可以接受,事实证明SQLMapping是替换掉JDBC的最好方式,如果你现在还在执意于使用直接使用JDBC的话,换 SQLMapping好了,效率不低,开发起来跟直接直接使用JDBC差距不大,iBatis就不错。

O/RMapping是一个重头戏,它是目前唯一的一种用面向对象的方式解决关系型数据库持久化问题的方法(我觉得也是目标明确的方法)。有趣的是,关系 型模型的范围要比对象化模型宽泛,这样就造成了,过去的系统设计中对对象化模型考虑的不够,使得过去系统的中的数据存储方式对O/RMapping实现不 利(这是事实);还有就是很多数据为中心的业务处理(比如计算电费,报表数据处理),用对象化模型不太合适(注2),这种情况下,O/RMapping实 在是不能长袖善舞。

DataSet是一种万金油式的对象化解决方案,处理小型的项目绰绰有余,处理大型的项目就有点力不从心了。万金油式的解决方案最大的缺点就是高不成、低不就,虽然在使用上它是相对简单的。我倒没有说ADO.NET本身有问题,其实.NET也有O/RMapping啊。

综上所述,我们可以得出结论。目前而言所有流行的持久层实现方式都有其优点和缺点(技术辩证法)。作为商业化的企业级应用而言,一个技术坚持到底的 路是走不通的(肯定会在技术的缺点上吃大苦头)。我推荐至少要使用两种以上的技术进行持久层封装(我推荐O/RMapping + SQLMapping + JDBC——实在是解决不了的问题再找JDBC),要采用务实的方式进行技术选择,而不要迷信哪一种技术,对于大型企业级开发而言,目前没有银弹。

注1:按我的话说是Dirty Work
注2:本身可重用性就不够(各处的算法都有不同),但是对运行时效率的要求却很高(有的时候甚至Java本身的效率都不足以达到要求,只能求之于其他语言)

posted on 2006-03-21 10:29 guitarpoet 阅读(1522) 评论(2)  编辑  收藏 所属分类: 持久层

Feedback

# re: JavaEE持久层开发方式现状和简单评价 2006-03-21 16:53 Flyingis

在设计理论中一直推荐低耦合的分层设计,但实际工作中不一定如此。非常同意楼主利用多种技术对持久层封装,来利于项目的推进,满足项目的需要。  回复  更多评论   

# re: JavaEE持久层开发方式现状和简单评价 2006-03-21 17:05 guitarpoet

实际工作中不完全遵照低耦合的分层设计其最主要的原因就是现实情况要比理论要复杂一些,如果放在以前的话,真是不太可能。但是目前来看我觉得还是有希望的,在接下来的几天里,我就把我现在正在使用的技术设计方案贴上来。这样也可以对这一种方式是否真的合乎生产实践和能对软件开发成本的降低起作用进行一下探讨。  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航: