开发J2EE应用的要领

J2EE，作为开发关键任务企业应用程序的标准集成平台。规范多，内容广，给J2EE应用的开发带来了很多麻烦。例如，要实现内容的RDBMS存储，我们可能会用到JDBC、实体Beans、JDO、O/R映射工具(TopLink、Hibernate)、XML-DBMS、JAXB等方法(其中有些方法是J2EE规范中没有的)。因此，为了实现J2EE各层(至少三层，包括表示层、控制层和业务逻辑层)之间的耦合，J2EE系统架构师需要考虑很多问题。此外，J2EE本身的快速发展也给具有工业实力的J2EE应用的架构和开发带来了一些困难。

同时，软件开发技术从来没有灵丹妙药，所以J2EE技术也不是万能的。但是，如果我们根据具体的业务需求合理地应用J2EE技术，结果是可想而知的。本文从本人以往的项目经验出发，尝试探讨开发J2EE应用应遵循的一些准测试，以期起到抛砖引玉的作用。如果能达到这个要求，我会很兴奋。

本文以JBoss 3.2.1下的J2EE应用开发为例进行讨论。

1.结合业务需求选择合理的架构

如果脱离业务需求，仅仅讨论技术本身的优势是不够的。每种技术都有其特定的背景，其中许多技术都受到行业需求的影响。一般来说，企业信息系统要求自身稳定、安全、可靠、高效、易维护。同时，每个企业信息系统都有自己独特的需求，有时可能需要考虑与原有遗留系统的集成。因此，了解每个企业信息系统的具体业务需求对整个系统的架构至关重要。

例如，如果待开发的J2EE应用系统中使用的大部分数据来自外部数据源；这些数据可从外部数据源直接输入将通过JDBC开发的J2EE系统的数据库。对于这种情况，如果在开发过程中只使用JDBC操作数据库，显然适用于低强度(并发用户少，数据流少)的情况；但如果并发用户多，数据流量大，频繁使用数据库层，就显得有点力不从心了。所以对于这种需求，可以考虑采用带缓存的实体Beans。比如在JBoss 3.2.1中，实体Beans的缓存策略有很多。这时可以考虑使用“标准CMP 2.x EntityBean”，采用“D”类型的commit-option，保证实体Bean的内容与数据源的同步，大大提高系统的性能(与直接使用JDBC相比)。其中，一些实体Beans可以设置为只读以提高性能。

当然，这里也可以使用其他O/R映射技术，比如TopLink。

再举个例子，考虑这样一种情况:如果待开发的企业信息系统所使用的数据全部由系统自己生成和操作，建议采用CMP实体Beans技术。实体豆给你的印象不好，可能和EJB 1.1形象不好有关。但是EJB 2.0(或者2.1)有了很大的改进，包括本地接口、CMR、只读、Session Fa & ccedilAde模式为实体豆注入活力。当然，使用实体Beans的优势只有在并发用户多、数据流量大的情况下才会体现出来。其中有一个重点是要注意实体Beans技术的性能调优，每个应用服务器都有自己的一套性能调优方案。对于JBoss 3.2.1，配置文件standardjboss.xml提供了实体Beans技术调优的入口点。例如，Bean锁策略的合理使用对于实体Bean的调优非常重要。这样我们可以更加关注系统的业务逻辑，而不仅仅是底层数据库(EJB调优是在EJB容器中，所以我们处于J2EE性能的高端，而不是底层，也就是数据库层。同时，数据库层调优使得J2EE系统的数据库可移植性大大降低。)。

总之，要根据每个系统的具体需求和条件，给出具体的技术架构方案，而不是单纯讨论技术本身的好坏。

2、框架的合理选择

模式在J2EE应用系统中起着重要的作用。所以，摆在大家面前的是一个问题，具体的设计模式是自己实现还是借助第三方框架实现。如果你的公司不大，或者你的公司不想在J2EE的基础应用框架上投入大量的精力，那么选择现有的成熟稳定的技术框架兼容现有的J2EE规范将是明智的。

总的来说，框架本身，或者说J2EE平台本身，已经实现并优化了特定的设计模式和规则，比如业务代理、服务定位器(包括Web层和EJB层各自的服务定位器，它们在管理有限的资源和缓存相关的资源方面起到统一的作用，方便系统移植)、前台控制器、DAO等等。现有的J2EE框架非常丰富。例如:

Struts:对于实现Model 2的框架来说，现在和将来选择她都是明智之举(随着JSF规范和技术的成熟)。目前Struts已经发展到1.1版本。其内部的MVC主线，对后端数据操作方式的无限制，以及Apache Jakarta项目组优秀相关项目的精髓，可谓是开发J2EE应用的最佳产品。同时，为下一代J2EE平台技术JSF与。NET Web Forms功能，Struts本身可以考虑与JSF的兼容性和集成性。例如，使用了JSP表现层、Servlet表现控制层和EJB表现数据存储层。各层之间可以通过值对象和HTTP相关对象进行通信，实现J2EE相关技术的完美应用。