《开发j2ee应用遵循的关键问题》由会员分享，可在线阅读，更多相关《开发j2ee应用遵循的关键问题（6页珍藏版）》请在金锄头文库上搜索。
1、开发开发 J2EEJ2EE 应用遵循的关键问题应用遵循的关键问题J2EE，作为开发 mission-critical 的企业级应用的一整套规范的整合平台，规范多、内容广，从而给开发 J2EE 应用带来了很多“麻烦”。比如，为实现内容的 RDBMS 存储，我们可能的方法有JDBC、Entity Beans、JDO、O/R Mapping 工具（TopLink、Hibernate） 、XML-DBMS、JAXB 等方法（其中一些方法不是 J2EE 规范所包含的） 。因此，为实现 J2EE 各层（至少有表示层、控制层、商业逻辑层等 3 层）以及层与层之间的耦合，J2EE 系统架构师需要考虑的问题会很
2、多。加上，J2EE 本身的快速发展，给架构、开发具有工业强度的 J2EE 应用带来一些难题。同时，软件开发技术从来就没有“银弹”，所以 J2EE 技术也不是万能的。但是，如果我们在结合具体商业需求的基础上，合理的应用好 J2EE 技术，其结果可想而知。本文试图从本人以往的项目经验入手，来探讨开发 J2EE 应用时应该遵循的几点准则。本文结合 JBoss 3.2.1 下的 J2EE 应用开发为例展开论述。1.结合商业需求选择合理的架构如果脱离商业需求，而单独的讨论技术本身的优势是不够的。各项技术都有产生的特定背景，其中很多都是来自工业需求而触动的。一般而言，企业信息系统（EIS）都要求自己稳定、
3、安全、可靠、高效、便于维护。同时，各个企业信息系统都有自己独特的要求，可能有些时候需要考虑与原有遗留系统的集成，所以了解各个企业信息系统具体的商业需求对于整个系统的架构显得很关键。比如，如果待开发的 J2EE 应用系统中使用到的数据大部分来自于外在数据源；而这些数据可能是通过 JDBC 直接从外在数据源导入到待开发的 J2EE 系统的 Database 中。对于这种情形，如果在开发过程中，仅仅使用 JDBC 来操作数据库，对于小强度（并发访问用户少、数据流量少）的情形，显然是比较合适的；但如果，并发访问用户较多、数据流量大，对 Database 层使用较为频繁的情形，则显得有些力不从心。因此，
4、对于这种需求，我们可以考虑采用 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.
5、再比如，考虑这样一种情形：如果待开发的企业信息系统使用到的数据都是由系统本身生成和操作的，则建议采用：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 技术的性能调优，各个应用服务器都有
6、自己的一套性能调优方案。对于JBoss 3.2.1，配置文件 standardjboss.xml 提供了 Entity Beans技术调优的入口。比如，Bean Lock 策略的合理使用对于 Entity Beans 的调优就显得很重要。这样使得，我们可以更加关注于系统的商业逻辑，而不只是底层的 Database（EJB 调优处于 EJB Container 中，因此我们处在 J2EE 性能的高端，而不是底端，即Database 层。同时，Database 层的调优使得 J2EE 系统的数据库移植性大打折扣。 ） 。简而言之，要结合各个系统的特定需求和状况给出具体的技术架构方案，而不能孤单的论
7、述技术本身的好坏。2.Framework 的合理选用设计模式在 J2EE 应用系统中扮演着重要的角色。因此，有一个问题摆在大家面前，是自己来实现具体的设计模式，还是借助于Third-party Framework.如果贵公司不大，或者说公司不想在 J2EE基础应用 Framework 投入很多精力，选用现有的较为成熟的、稳定、与现有 J2EE Specification 兼容的技术框架会比较明智。一般而言，Framework 本身，或者说 J2EE 平台本身都是实现并优化了具体的设计模式、规则，比如业务代理、Service Locator（包括 Web Tier 和 EJB Tier 各自的服
8、务定位器，起到统一管理有限资源、Cache 相关资源的作用，便于系统移植） 、Front Controller、DAO 等等。现有的 J2EE Framework 比较丰富。比如：Struts： 对于实现了 Model 2 类型的 Framework，对于现在以及将来（随着 JSF 规范、技术的成熟） ，选用她是一种明智之举。目前，Struts 已经发展到 1.1 版本。其内在的 MVC 主线、对后端数据操作方式没有限定、集合了 Apache Jakarta 项目组的优秀相关项目的精华，可谓是开发 J2EE 应用的佳品。同时，对于具有。NET Web Forms 功能的下一代 J2EE 平台技
9、术 JSF 而言，Struts 本身可考虑到与 JSF 的兼容和集成性。比如，通过 JSP 呈现表示层、Servlet 呈现控制层、EJB 呈现数据存储层。各层之间，可以通过值对象、HTTP 相关对象来通讯，实现 J2EE 相关技术的完美应用。Log4j： 我想对于习惯采用“System.out.println（” “） ；”的读者而言，Log4j 是大家的福音。尽管 Java 2 Standard Edition也具备 java.util.logging 包来保证日志的输出，但 Log4j 的简单、高效、灵活已经成了很多项目的选择。日志，在某种程度上可以考验系统的稳定性、正确性，所以采用可配
10、置的 Log4j（目前，Log4j已经考虑到了与 java.util.logging 包的兼容性）是不会错的。比如，JBoss 3.2.1 本身就是借助于 Log4j 来管理日志的。realMethods： 可能有些读者还不知道这一款杀手锏。那好，这里就简要作一介绍。realMethods 是一开发 J2EE 应用的Framework，她不同于 Struts（主要在于实现 Model 2，J2EE 应用前端） ；realMethods 对于 J2EE 应用的各个层面都有详尽、高效的支持。同时，realMethods 以前还是商用软件，现在已经成为了Open Source 的产品，因此现在可以参
11、看其全部源代码。BC4J： Oracle 公司推出的用于 Java 的商业组件。其内容和外在的特点和优势，不言而喻。当然，类似的 Framework 很多很多。作为开发 J2EE 应用的团队而言，我们需要对各种 Framework 加以筛选，选择适合项目需求、团队、公司发展方向的框架。一般情况下，待开发的目标产品不宜采用过多的 Framework.其一，J2EE 各个技术发展很快，过多的 Framework 使得系统的后续升级、维护不利；其二，可以借鉴其中的好的一面，比如研究realMethods 实现的相应的设计模式，并改造她以适合我们的项目需求；其三，Framework 本身会有变动，如果
12、选用过多，会给开发团队加重负担，从而不利于项目管理。有选择的使用现有的成熟Framework 能提升大家的开发效率、开发水平。3，开发模式的选择开发 J2EE 应用要求目标开发人员能够掌握其中的各种技术。但是，现实情况不是这样。作为一个团队，每个人都有自己不同的技能优势、兴趣以及悟性。同时，J2EE 本身需要体现社会分工。一般情况下，我们的开发团队不会有 Specification 所要求的各个开发角色。现实往往只有 3 种（也可能是两种）：美工、JSP 程序员、EJB 程序员。面对这种分工，团队更要注重沟通、交流，注重代码的一致性。一般情况下，团队要尽量采用版本控制工具管理代码、尽量做到每天
13、都有一个完整的运行版本。经过一段时间，团队都会适应这种开发模式。其中，版本控制工具一定要使用，便于代码的管理、控制和备份。这其中会牵扯到很多层面。比如，开发工具的选择要考虑到版本控制工具的使用、建模工具的合理使用有助于团队有效的沟通和交流。基于现有的开发模式，个人认为这样 3 套方案不错。第一，采用 Together 作为建模工具、采用 JBuilder 作为 IDE 工具、采用VSS（或者 CVS）作为版本控制工具、采用 JBoss 作为开发 J2EE 应用开发阶段的服务器。第二，采用 WebSphere Studio 整套工具。第三，采用 Eclipse（或者 JCreator） 、Ant
14、、XDoclets 作为开发工具。当然，手工完成 J2EE 应用的编写、编译、打包、部署、测试更能使开发者理解各个开发阶段的具体细节。但本人认为，只要开发者有这种关注具体细节的态度，选用功能强大的建模、开发工具是明智的。开发工具不能提高开发人员的开发技能，但是她能够引导开发人员正确的开发方向。比如，JBuidler 9 Enterprise 提供的EJB 精灵具有的“Struts + EJB + Session Fa？ade + Value Object”等功能呈现了业界广泛应用的 J2EE 构架方式。4，注重各个阶段的测试工作测试工作往往是很多项目经理忽视，不愿意去花费时间、费用的内容，因为
15、那样会增加项目的成本。但是，他们忽视了，项目的完成质量往往对项目的成本有很大的关系。比如，如果软件质量很差，并没有经历测试阶段，其后期部署、运行所带来的费用会远远超过前期的费用。测试是分阶段的。单元测试，比如借助于 JUnit，来保证功能正确等内容。集成测试，来保证系统没有内存泄漏等内容。其中，Optimizeite Suite Enterprise 对于完成 Profiler、Code Coverage、Thread Debugger 等内容很有帮助。我记得，我写的一个 Swing 桌面应用存在内容泄漏，但是想了很多办法都没有解决问题。后来，采用 Profiler 获得了答案。因此，现在开发
16、应用，我们很多时候都采用 Optimizeite Suite Enterprise 作为测试工具。尤其是，在做集成测试过程中，检查系统的内存泄漏、性能很有帮助。测试是分类型的。压力测试、性能测试。就目前对支持 J2EE 应用的测试而言，并没有很好的测试工具。但是，一般情况下，借助于 Rational Robot 也能够取得不错的效果。 功开发 J2EE 应用的因素有很多。比如，Entity Beans 的成功应用很大程度上与底层Database 的设计有关系（如果表结构设计设计的不合理，将导致Entity Beans 性能的急剧下降） ；如何最大化挖掘、提升团队各个成员的 J2EE 技能。等等这些，设计面很广。
