开发J2EE应用遵循的关键问题

开发J2EE应用遵循的关键问题

J2EE，做为开发mission-critical的企业级应用的一整套规范的整合平台，规范多、内容广，从而给开发J2EE应用带来了不少“麻烦”。好比，为实现内容的RDBMS存储，咱们可能的方法有JDBC、Entity Beans、JDO、O/R Mapping工具（TopLink、Hibernate）、XML-DBMS、JAXB等方法（其中一些方法不是J2EE规范所包含的）。

所以，为实现J2EE各层（至少有表示层、控制层、商业逻辑层等3层）以及层与层之间的耦合，J2EE系统架构师须要考虑的问题会不少。加上，J2EE自己的快速发展，给架构、开发具备工业强度的J2EE应用带来一些难题。同时，软件开发技术历来就没有“银弹”，因此J2EE技术也不是万能的。可是，若是咱们在结合具体商业需求的基础上，合理的应用好J2EE技术，其结果可想而知。本文试图从本人以往的项目经验入手，来探讨开发J2EE应用时应该遵循的几点准则。本文结合JBoss 3.2.1下的J2EE应用开发为例展开论述。

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

若是脱离商业需求，而单独的讨论技术自己的优点是不够的。各项技术都有产生的特定背景，其中不少都是来自工业需求而触动的。通常而言，企业信息系统（EIS）都要求本身稳定、安全、可靠、高效、便于维护。同时，各个企业信息系统都有本身独特的要求，可能有些时候须要考虑与原有遗留系统的集成，因此了解各个企业信息系统具体的商业需求对于整个系统的架构显得很关键。

好比，若是待开发的J2EE应用系统中使用到的数据大部分来自于外在数据源；而这些数据多是经过JDBC直接从外在数据源导入到待开发的J2EE系统的Database中。对于这种情形，若是在开发过程当中，仅仅使用JDBC来操做数据库，对于小强度（并发访问用户少、数据流量少）的情形，显然是比较合适的；但若是，并发访问用户较多、数据流量大，对Database层使用较为频繁的情形，则显得有些力不从心。

所以，对于这种需求，咱们能够考虑采用Entity Beans with Caches.打个比方，在JBoss 3.2.1中对于Entity Beans的Cache策略有多种，这时能够考虑使用，，即“Standard CMP 2.x EntityBean”，方式并采用“D”类型的commit-option来保证Entity Beans的内容与数据源的同步，并使得系统的性能获得大大改善（同直接使用JDBC相比）。其中，能够将一些Entity Beans设置为read-only，以改善性能。固然，在这里也能够采用其余一些O/R Mapping技术，好比TopLink.

再好比，考虑这样一种情形：若是待开发的企业信息系统使用到的数据都是由系统自己生成和操做的，则建议采用：CMP Entity Beans技术。Entity Beans给你们的印象很坏，这可能与EJB 1.1给你们留下的坏映象有关吧。可是，EJB 2.0（或者说2.1）获得了很大的改善，Local Interfaces、CMR、Read-Only、Session Fa？ade模式给Entity Beans注入了活力。

固然，并发用户多、数据流量很大时才会体现出使用Entity Beans的优点。其中，有一点很关键：要注重Entity Beans技术的性能调优，各个应用服务器都有本身的一套性能调优方案。对于JBoss 3.2.1，配置文件standardjboss.xml提供了Entity Beans技术调优的入口。好比，Bean Lock策略的合理使用对于Entity Beans的调优就显得很重要。这样使得，咱们能够更加关注于系统的商业逻辑，而不仅是底层的Database（EJB调优处于EJB Container中，所以咱们处在J2EE性能的高端，而不是底端，即Database层。同时，Database层的调优使得J2EE系统的数据库移植性大打折扣。）。

简而言之，要结合各个系统的特定需求和情况给出具体的技术架构方案，而不能孤单的论述技术自己的好坏。

2.Framework的合理选用

设计模式在J2EE应用系统中扮演着重要的角色。所以，有一个问题摆在你们面前，是本身来实现具体的设计模式，仍是借助于Third-party Framework.若是贵公司不大，或者说公司不想在J2EE基础应用Framework投入不少精力，选用现有的较为成熟的、稳定、与现有J2EE Specification兼容的技术框架会比较明智。

通常而言，Framework自己，或者说J2EE平台自己都是实现并优化了具体的设计模式、规则，好比业务代理、Service Locator（包括Web Tier和EJB Tier各自的服务定位器，起到统一管理有限资源、Cache相关资源的做用，便于系统移植）、Front Controller、DAO等等。现有的J2EE Framework比较丰富。好比：

Struts： 对于实现了Model 2类型的Framework，对于如今以及未来（随着JSF规范、技术的成熟），选用她是一种明智之举。目前，Struts已经发展到1.1版本。其内在的MVC主线、对后端数据操做方式没有限定、集合了Apache Jakarta项目组的优秀相关项目的精华，可谓是开发J2EE应用的佳品。同时，对于具备。NET Web Forms功能的下一代J2EE平台技术JSF而言，Struts自己可考虑到与JSF的兼容和集成性。好比，经过JSP呈现表示层、Servlet呈现控制层、EJB呈现数据存储层。各层之间，能够经过值对象、HTTP相关对象来通信，实现J2EE相关技术的完美应用。

Log4j： 我想对于习惯采用“System.out.println（”“）；”的读者而言，Log4j是你们的福音。尽管Java 2 Standard Edition也具有java.util.logging包来保证日志的输出，但Log4j的简单、高效、灵活已经成了不少项目的选择。日志，在某种程度上能够考验系统的稳定性、正确性，因此采用可配置的Log4j（目前，Log4j已经考虑到了与java.util.logging包的兼容性）是不会错的。好比，JBoss 3.2.1自己就是借助于Log4j来管理日志的。

realMethods： 可能有些读者还不知道这一款杀手锏。那好，这里就简要做一介绍。realMethods是一开发J2EE应用的Framework，她不一样于Struts（主要在于实现Model 2，J2EE应用前端）；realMethods对于J2EE应用的各个层面都有详尽、高效的支持。同时，realMethods之前仍是商用软件，如今已经成为了Open Source的产品，所以如今能够参看其所有源代码。

BC4J： Oracle公司推出的用于Java的商业组件。其内容和外在的特色和优点，不言而喻。

固然，相似的Framework不少不少。做为开发J2EE应用的团队而言，咱们须要对各类Framework加以筛选，选择适合项目需求、团队、公司发展方向的框架。

通常状况下，待开发的目标产品不宜采用过多的Framework.其一，J2EE各个技术发展很快，过多的Framework使得系统的后续升级、维护不利；其二，能够借鉴其中的好的一面，好比研究realMethods实现的相应的设计模式，并改造她以适合咱们的项目需求；其三，Framework自己会有变更，若是选用过多，会给开发团队加剧负担，从而不利于项目管理。有选择的使用现有的成熟Framework能提高你们的开发效率、开发水平。

3，开发模式的选择

开发J2EE应用要求目标开发人员可以掌握其中的各类技术。可是，现实状况不是这样。做为一个团队，每一个人都有本身不一样的技能优点、兴趣以及悟性。同时，J2EE自己须要体现社会分工。通常状况下，咱们的开发团队不会有Specification所要求的各个开发角色。现实每每只有3种（也多是两种）：美工、JSP程序员、EJB程序员。面对这种分工，团队更要注重沟通、交流，注重代码的一致性。

通常状况下，团队要尽可能采用版本控制工具管理代码、尽可能作到天天都有一个完整的运行版本。通过一段时间，团队都会适应这种开发模式。其中，版本控制工具必定要使用，便于代码的管理、控制和备份。这其中会牵扯到不少层面。好比，开发工具的选择要考虑到版本控制工具的使用、建模工具的合理使用有助于团队有效的沟通和交流。

基于现有的开发模式，我的认为这样3套方案不错。第一，采用Together做为建模工具、采用JBuilder做为IDE工具、采用VSS（或者CVS）做为版本控制工具、采用JBoss做为开发J2EE应用开发阶段的服务器。第二，采用WebSphere Studio整套工具。第三，采用Eclipse（或者JCreator）、Ant、XDoclets做为开发工具。

固然，手工完成J2EE应用的编写、编译、打包、部署、测试更能使开发者理解各个开发阶段的具体细节。但本人认为，只要开发者有这种关注具体细节的态度，选用功能强大的建模、开发工具是明智的。开发工具不能提升开发人员的开发技能，可是她可以引导开发人员正确的开发方向。好比，JBuidler 9 Enterprise提供的EJB精灵具备的“Struts + EJB + Session Fa？ade + Value Object”等功能呈现了业界普遍应用的J2EE构架方式。

4，注重各个阶段的测试工做

测试工做每每是不少项目经理忽视，不肯意去花费时间、费用的内容，由于那样会增长项目的成本。可是，他们忽视了，项目的完成质量每每对项目的成本有很大的关系。好比，若是软件质量不好，并无经历测试阶段，其后期部署、运行所带来的费用会远远超过前期的费用。

测试是分阶段的。单元测试，好比借助于JUnit，来保证功能正确等内容。集成测试，来保证系统没有内存泄漏等内容。其中，Optimizeite Suite Enterprise对于完成Profiler、Code Coverage、Thread Debugger等内容颇有帮助。我记得，我写的一个Swing桌面应用存在内容泄漏，可是想了不少办法都没有解决问题。后来，采用Profiler得到了答案。所以，如今开发应用，咱们不少时候都采用Optimizeite Suite Enterprise做为测试工具。尤为是，在作集成测试过程当中，检查系统的内存泄漏、性能颇有帮助。

测试是分类型的。压力测试、性能测试。就目前对支持J2EE应用的测试而言，并无很好的测试工具。可是，通常状况下，借助于Rational Robot也可以取得不错的效果。 功开发J2EE应用的因素有不少。好比，Entity Beans的成功应用很大程度上与底层Database的设计有关系（若是表结构设计设计的不合理，将致使Entity Beans性能的急剧降低）；如何最大化挖掘、提高团队各个成员的J2EE技能。等等这些，设计面很广。