大音希声、大象无形

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

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

开发方式大体以下几种方式（括号内为目前使用它的工作难度、强度，记住，我们讨论的是动辄就上百个表、几个业务小组联合开发的企业级应用，所以工作强度的估计一点儿也没有夸张）：

直接JDBC操作（简单，小）：底层操作（注1）较多，弄不好就会造成业务逻辑层和持久层的高度耦合。
SQLMapping（比较简单，一般）：把底层操作全部提取出来统一进行管理，本身并没有对概念上进行什么革新。但是这种统一的处理在逻辑上其实属于分而治之的逻辑，通过良好的对它的使用可以体现出松耦合实现持久层的要求，也相对比较便于管理和修改。
O/RMapping（有学习曲线，没有工具支持会相当大）：存在的时间已经很长，我认为它的最主要的作用是关系型数据库的反设计——关系型数据库的设计就是要把现实中的对象和对象间关系设计成实体和实体间的关系映射。而O/RMapping恰好相反，它是把实体和实体间的关系映射还原回对象和对象间的关系。
Entity EJB（有学习曲线，没有工具支持会相当大）：我没有对它进行过深入的研究，但是从J2EE的概念上看，它是属于O/RMapping概念的一种。它既是一个事实上的工业标准而且又体现了EJB的容器管理特性。本身其实是很值得研究的，但是由于目前而言EJB3.0刚刚起步，而EJB2.0的开发也确实比较麻烦，还有等等等等一系列的其他事情，我对它暂时处于观望态度。
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 @ 2006-03-21 10:29 guitarpoet 阅读(1522) | 评论 (2) | 编辑收藏

企业级应用为什么要分层？

首先，需要知道什么是企业级应用。

企业级应用（enterprise applications），其实是一个软件行业内部通用的一个术语。如果解释成通俗易懂的话来说，那就是一个企业范围内所使用的、基于计算机的稳定的、安全的和高效的分布式信息管理系统。
对于企业级应用而言它的分布式有两种形式：B/S结构和C/S结构。由于浏览器的功能日益强大、网页技术的日益流行和应用服务器软件和中间件产品的逐步成熟，B/S结构的企业级应用已经成为一种流行的趋势，所以在下面的讨论中所谓的企业级应用统一为基于B/S结构的分布式企业信息系统。

一般说来企业级应用都可以分为三层持久层（Persistence Layer）、业务逻辑层（Business Logic Layer）和展现层（Presentation Layer ）。
为什么要分这么几个层次呢？
归根结底主要原因只有一个——那就是提高软件开发生产力，降低软件开发成本，提高软件产品质量。
因为软件公司也是资本公司，公司的主要目标是盈利而不是科技发展。所以，公司的技术架构的优劣主要应该体现在公司的生产成本和产品的质量上。
对于降低软件产品的开发成本是软件产品出现以来所有软件公司所追求的目标。到目前为止，达到这个目标的方式有这么几种：

把软件产品根据功能进行分解，分别开发：对于大的复杂系统，如果没有很好的分解开发的话，其结果是不可想象的。现实中企业需要分开各个职能部门，它们的职责和业务是不同的，这样开发中需要根据业务进行任务分解，把大的系统分解成为小的业务系统。这样才能够实现系统开发过程中的并行开发，并且会培养业务专精人员，提高开发的效率。
业务系统根据技术架构进行分层开发：分层的开发方式实现了人类对复杂事物的普遍处理方式——分而治之。通过把复杂的系统分解成为相对简单的独立系统，低耦合的分解既可以实现开发人员的并行工作，又可以实现开发人员的任务分工。而且通过分层，对组件拼装和流水化作业提供了理论和事实的基础。
组件拼装实现社会化分工：不必自己去创造轮子，直接付钱去买想要的轮子即可。这是从传统的制造行业借鉴来的经验。J2EE得到的广泛认同从实质上体现了业界对这种方式的肯定。
过去经验的积累和积累资源的重复利用：重用一直是一个争议比较大的东西，争论的双方各执一词，各有道理也各有大师助阵，但是那更多的是在理论上和技术层面上。理论和技术上的争论对商业软件开发是无用的。因为商业化的软件开发，最重要的是提供优质的产品和服务并且能够最大可能的获取利润。所以，抛开具体实现方式不谈，我个人觉得公司过去经验的积累和积累资源的重复利用是有商业价值的。因为软件公司必须得面对开发人员流动的问题，不管是升迁还是调动还是跳槽，软件公司总会面对业务专精人员的流失问题。业务专精人员的流失造成的成本是要计算在开发成本中的，所以怎样以固化的形式积累业务人员的经验，和过去解决问题的方案的可重复利用以及新员工职业培训成本的降低在降低开发成本的方面是值得考虑的。

综上所述，对于一个企业级应用框架（还有人开发企业级应用不用框架吗？）而言，分层是提高开发效率、降低开发和培训成本的最佳实践方案之一。
但是，为什么要分为持久层（Persistence Layer）、业务逻辑层（Business Logic Layer）和展现层（Presentation Layer ） 3层呢？
其实这三层不过就是从三个不同的视角去看这个企业信息系统罢了。从数据的角度看，企业信息系统不外乎就是对数据的存取。从功能的角度看，企业信息系统就是对现实中的业务逻辑操作的信息化抽象而从用户的角度上看，它是一个人机接口，它可以接受输入并且会对所做的输入做出相应的反应。这三层从底向上实现了底层计算机数据和顶层人的业务操作的跨越，一般说来，从概念上讲，所有的企业级应用框架都可以分成这三层，因为这三个视角是客观的。但是这并不保证所有的企业级应用都能保证这三个层之间不发生耦合。

posted @ 2006-03-20 17:29 guitarpoet 阅读(1693) | 评论 (0) | 编辑收藏

开宗明义

“其安易持，其未兆易谋。其脆易泮，其微易散。为之於未有，治之於未乱。合
抱之木生於毫末。九层之台起於累土。千里之行始於足下。为者败之，执者失之。
是以圣人无为故无败，无执故无失。民之从事常於几成而败之。慎终如始则无败
事。是以圣人欲不欲，不贵难得之货。学不学，复众人之所过，以辅万物之自然而
不敢为。”
——《道德经》，老子

这是我的一个关于Java技术的Blog，为什么要写这个Blog？

答案有四：