J2EE开发框架

J2EE开发框架

 

Rod Johnson

 

Java2企业版为中间件领域思想的统一上发挥了很大的作用。比如，J2EE为分布式事务管理、目录服务和消息服务提供了一套标准的编程接口。J2EE的基础——Java2标准版(J2SE) ，成功地为Java提供了一套访问关系数据库的标准。

但是，就像本文中“J2EE缺乏对编程的支持”提到的一样，J2EE这个平台没有能够提供一个令人满意的应用程序编程模型（application programming model）。Sun公司和一些大的应用服务器供应商都想用开发工具来降低J2EE开发的复杂性，但是这些工具没有其他的JAVA 开发工具优秀，后者有先进的重构工具，和.NET平台相比，J2EE的工具支持显得很逊色。

很多J2EE开发工具自动产生的代码像这些工具本身同样复杂。在开源社区很多小型J2EE开发者选择了另外一种开发方式—— 一些可以降低J2EE开发难度的开发框架,较为流行的比如：  Struts, Hibernate, 和 Spring Framework，他们当今很多J2EE项目种扮演着重要角色。

 

为什么要采用框架？

 

框架是一由一些类组成，正式这些类为应用程序提供了一个可重用的设计――或者我们经常提到的——应用程序种的一层。应用程序代码访问类库从而执行任务，而框架是调用应用程序代码，从而管理程序的流程。这就是经常说道的好莱坞原则：“不要试图联系我们，我们到时候自会通知你。”开发者写的程序在运行时由框架调用。

设计一个在各种未知背景下都可以使用的框架是很有挑战性的。框架很适合在复杂的J2EE开发中使用，它可以为开发者提供一个简单易用的模型。采用一个经过良好设计的开源框架有很多好处：

Ÿ           在好的框架下，开发者只需要写一些必须的代码；他们不需要直接接触底层的API。  这一点很重要。

Ÿ           经过良好设计的框架可以为程序提供清晰的结构并且提高程序的内聚性。好清晰的结构使得其他人可以更容易加入项目。

Ÿ           一个容易使用的框架可以通过一些例子和文档为用户提供最佳实践。

Ÿ           采用成功的框架的代码比自己的代码容易测试

Ÿ           框架只有提供了一些值得使用的功能才会变得流行。J2EE工程只有真正需要框架的时候才会用它，而自己的框架并不是这样，后者是处于统治地位的。

J2EE本身也提供了一些框架。比如， Enterprise Java-Beans (EJB) container或者 Servlet engine，二者都运用了“ 采用了好莱坞原则”这个思想，并采用运行时调用来管理对象。像Struts这些开源web应用框架正式建立在这两个框架的基础上的，本文讨论的重点也是像Struts这样建立在J2EE上的框架，他们为开发者提供了更为简单的模型，和其他的一些好处。

 

开源框架的出现。

 

很多大型的J2EE项目都用自己的内部框架来隐藏平台的复杂性，直到最近人们才逐渐发现一些在很多项目中都存在的共有的难题，这些难题都可以由一个较为统一的解决方案来解决。而有的框架正好可以充当这些问题的解决方案。现在有种很明显的趋势：与从前的内部框架相比，这些框架将成为这些难题的更加“标准化 ”的解决方案。

 

J2EE平台的日益成熟是这些框架流行的一个原因。开发者知道有些地方是J2EE的标准API无能为力的，倚他们的经验来看，要弥补这个缺陷是很困难的。于此同时，一些优秀的开源框架可供使用，它们提供了极为丰富的技术文档，在它们背后还有一个专业的团队做支持，并且一切都是免费的。

 

 

Struts。在web应用程序产生的那时就有了开源框架。在1999－2000年，开发者们意识到JSP“Model1”的缺陷，JSP中充斥着请求处理代码和静态数据模板，这意味着你不得不把业务逻辑和复杂的HTML以及其他的标签混到一起。那个时候还没有标准的框架和J2EE的标准支持，要解决这个问题开发者就得自己实现前端控制器，这样可以把业务逻辑分离到java类中，从而可以减轻对JSP的维护难度。前端控制器模式经常运用在MVC架构中，MVC模式在OO语言的GUI开发中经常使用（这个名字总是让人误解，WEB MVC中的视图是从模型中“拉”数据；而在经典MVC中，模型把事件“推向”视图）。

最初的前端控制器实现质量参差不齐。2001～2002年间，Apache开源组织发布的Struts改变了这个状况，虽然它并非一个完美的框架，但已经足够使其成为该领域事实上的标准。

Struts向人们展示了开源框架的一些优点，比如，新手可以很容易地熟悉它的结构。2002年末，它成立很多J2EE项目很自然的选择，每一个认真的J2EE开发者都会对它很熟悉。

Struts几乎用才每一个J2EE项目中，这使得它成为J2EE架构的一个重要组成部分。甚至很多保守的组织也将其作为软件底层的一部分，并同意接受Apache的开源协议条款。

 

Hibernate。下一个倒下的多骨诺米牌就是持久化。J2EE提供了两个持久化的手段：JDBC，它是J2SE中访问关系数据库系统的标准API；另一个是实体Beans ,它是EJB中专门模型化持久化实体的组件。

JDBC以一种错误的编程模型来强制开发者用Java代码来处理关系思想。而实体beans，先不说Sun和其他主要的J2EE供应商的吹嘘，给人很笨重的感觉：起初这门技术的应用范围很窄，连持久对象间的关系都不能处理。它使得应用程序难于测试，并且使用了一个很糟糕的查询语言。直到2003年，即使EJB2.0和2.0做了很多改进，开发者们却很少用它。

 

早期的尝试。

持久化问题的解决方案是由关系-对象映射（ORM）来解决的，它可以透明地持久化普通java对象（POJO）。该思想在注释中有解释。虽然这种方案并不是专属java的。但相对与其他的社区而言比如.NET，ORM在java社区更加流行(.NET开发者总是对之抱有怀疑的态度)。

早在1990年，一些商业的ORM工具就出现了，比如TopLink。但由于其价格昂贵、结构复杂并且与Sun的实体bean标准相左，所以很少人会用。不管怎样，在持久化POJO方面，这些工具与JDBC和实体Bean相比确实有了很大的进步

Java Data Object于2001年在Java Community Progress(www.)的规范中出现。它为一般的POJO提供了大多数的持久化实现(尽管很多实现都是对关系数据库的)。但Sun公司以及其他的J2EE技术提供商对该技术表现的很冷淡。所以JDO也没有能够流行。

 

Hibernate的出现。ORM领域在2002年发生了大变化，原因有两个。首先，实体Beans在实践中失败，开发者们将其从J2EE中忽视掉了。它向开发者们说明了一个规范是如何将开发拉入泥潭的。

另外的一个原因是Hibernate的发布，它是第一个功能健全的解决关系对象影射解决方案。虽然在功能上，它没有TopLink多样。但在那些最常用的功能上，Hibernate实现的更加健壮，并且有一个非常专业的团队提供全职的开发。Hibernate并不是全新的，它的ORM思想在这个领域很普遍，但它提供的编程模型比其他任何竞争者都容易使用、都来的直接，它为ORM的使用提供了更加易用、廉价的途径。

于此同时，新一代的商业产品针对关系数据库提供了极其高效的JDO规范的实现。这样开发者的选择就更丰富了；还有，TopLink也朝着开发者友好的方向前进，它的liscense越来越开放了。

 

 

ORM大获全胜。

 

所的这些因素是的ORM比以往更加规范。虽然很多项目仍然使用自己的持久层框架，但Hibernate，TopLink以及一些高端的JDO实现，使得使用自己持久层框架的难度相对变大、可维护性降低，自然，也没有什么理由去使用自己的框架了。

虽然这些框架的功能覆盖范围已经很大了，但仍有很多地方不在其中。比如，一个基于struts，hibernate的项目，业务逻辑很难搞定。尽管对于这种问题，J2EE规范提出了解决方案（EJB），但仍旧没有一个合适的编程模型。

 

Spring

 

J2EE框架被大规模地运用到项目中，而项目总要负责这些框架以及自己业务代码的连接，使之真正融合到一起。Spring就是专注于这个问题的，它和Hibernate融合的很好。

本质上讲，Spring是IOC(Inversion of Control)和面向切面编程(AOP)的组合体。它是一个非侵入式的框架，增强了POJO的功能。从服务上讲(With a service abstraction)，它将程序代码从J2EE环境解耦到普通的java对象（自然，这些代码可以脱离J2EE而在多种环境中运行）。它还在很多功能上提供了除EJB之外的选择――比如为所有的POJO提供声明式事务。Spring被广泛运用到很多项目中，从小的web程序到大的企业应用程序。

在这个领域还有其他的产品，比如HiveMind和NamoContainer。前者和Spring的思想大致相同，只不过在IOC上有较大差异；后者将很多服务融合在PicoContainer的IOC容器中。这些产品的实现方式和J2EE的不同在于，它们都很轻便。

在有J2EE API下做测试是非常困难的，这些容器将POJO从J2EE API中脱离出来，从而大大降低了测试的难度。测试一个普通的java对象，不用象测试J2EE程序那样，得先将应用程序部署到服务器上，要不就得自己动手模拟J2EE环境。提供日益流行的测试驱动的开发环境（对于开发者来说这是应得的），是这些轻量容器流行的关键因素。

 

下一个将会是谁？

 

人们日益对开源框架的重视，使得很多项目的成本大大降低，并且投放使用以及维护速度都增加了。现在的开源框架都有很高的质量，都提供了很好的文档＆一些书籍让开发者做参考。即便如此，两大因素是的J2EE领域充满了不确定性：开源领域和J2EE“标准”的冲突和AOP的日益重要。

开源和标准之间的冲突表现在两个地方。一个是表现层，JSF的身后有Sun公司和其他的一些大公司，而在这个领域有Struts等开源产品与之竞争。在中间层，EJB 3.0采用J2SE5.0的annotations实现了依赖注入(dependency injection)的功能，但这个功能只是Spring的一个子集

在这两个领域，开源产品都更加革新。JSP借鉴了ASP.NET，而Tapestry则采用了WebObjects的思想。

同样的，不知道EJB3.0为何要尝试着标准化依赖注入，即使这样会使之不可避免地丧失很多功能。 EJB 3.0好像也要进入程序编写领域，而J2EE规范在这方面还没有涉足。

于此同时，AOP的重要性在J2EE社区猛增，在使用上，AOP也越来越受到开发者的青睐。像Spring、dynaop等被称作“带着双拐的AOP”实现提升了AOP的知名度。而纯粹的AOP技术比如AspectJ，在将来的几年也会流行起来。

其次，JBoss通过JCP和EJB3.0保持一致，它极大地推动了AOP技术。但即使如此，JCP 还没有转向AOP迹象。

下一代的J2EE规范将拥抱更简单的POJO编程模型，就像Spring和Hibernate做的一样。J2EE开发者也注定要从“欺诈客户”转到以自己的编程经验开发上来。这次改变将受到大多数人的欢迎，不像以前那样每一个新规范发布后，最终都没有能很好的实现。

   本位作者Rod Johnson 是Interface21的CEO。该公司是位于伦敦的一家J2EE咨询公司。他的联系方式是：[e-mail] 。

   编辑 Richard G. Mathieu,他是St. Louis大学Decision Sciences and MIS部门主任，他的联系方式： [e-mail]