2013第4周五最重要的J2EE实践摘录
1. 始终使用 MVC 框架。
MVC 框架可以将业务逻辑（Java beans 和 EJB 组件)、控制器逻辑（Servlets/Struts 动作）、表示层（JSP、XML/XSLT）清晰地分离开来。良好的分层可以带来许多好处。
MVC 框架对于成功使用 J2EE 是如此重要，以致没有其他最佳实践可以与其相提并论。模型-视图-控制器（MVC）是设计 J2EE 应用程序的基础。MVC 将您的程序代码简单地划分下面几个部分：
负责业务逻辑的代码（即模型——通常使用 EJB 或者普通的 Java 对象来实现）。
负责用户界面显示的代码（即视图——通常通过 JSP 及标记库来实现，有时也使用 XML 和 XSLT 来实现）。
负责应用程序流程的代码（即控制器——通常使用 Java Servlet 或像 Struts 控制器这样的类来实现）。
我们常常见到一些应用程序包含 servlet、JSP 和 EJB 组件所有这三项，然而，其主要的业务逻辑却是在 servlet 层实现的，或者应用程序导航是在 JSP 中处理的。您必须进行严格的代码检查并重构您的代码，以确保应用程序的业务逻辑只在模型层（Model layer）进行处理，应用程序导航只通过控制器层（Controller layer）进行处理，而您的视图（Views）只是将传递过来的模型对象以 HTML 及 JavaScript 的形式表示出来。
2. 在应用程序的每一层都使用自动单元测试和测试管理。
不要只是测试您的图形用户界面（GUI)。分层的测试使测试及维护工作变得极其简单。例如，JUnit（是一种由 junit.org开发的开放源代码工具）和 Cactus（由 Apache开发的开放源代码工具）对于测试 J2EE 组件都非常有用。 [Hightower]详细探讨了如何在 J2EE 中使用这些工具。
要将规范熟记于心，如果要背离规范，要经过慎密的考虑后才可以这样做。这是因为当您背离规则的时候，您所做的事情往往并不是您应该做的事情。要注意不要脱离 J2EE 规范提供的验证机制，如果脱离了此规范，这将是系统存在安全漏洞以及厂商兼容性问题的主要原因。类似地，要使用 servlet 和 EJB 规范提供的授权机制，并且如果您要偏离这些规范的话，要确保使用规范定义的 API（例如 getCallerPrincipal()）作为实现的基础。通过这种方式，您将能够利用厂商提供的强安全性基础设施，其中，业务要求需要支持复杂的授权规则。
启用 WebSphere 安全性。这使您的 EJB 和 URL 至少可以让所有授权用户访问。不要问为什么——照着做就是了。以我们的经验看来，大多数自己构建的安全性系统是不安全的，并且有重大的缺陷，这使产品系统极其脆弱（请参考 [Barcia]第 18 章）。
反复的开发工作将使您能够逐渐地掌握所有的 J2EE 模块。要从创建小而简单的模块开始而不是从一开始就马上涉及到所有的模块。最后，当您开发一些简单的模块时，在开始的初期就可以对您的应用程序进行性能测试。如果直到应用程序开发的后期才进行性能测试的话，这往往会出现灾难性的后果，正如 [Joines]所述。
6. 当使用 EJB 组件时，始终使用会话 Facades。
决不要将实体 bean 直接暴露给任何用户类型。对实体 bean 只可以使用本地 EJB 接口（Local EJB interfaces）。
7. 使用无状态会话 bean，而不是有状态会话 bean。
这样做可以使您的系统经得起错误的终止。使用 HttpSession 存储和用户相关的状态。我们建议对大多数应用程序使用无状态会话 bean 方法。任何在处理时需要使用的与用户相关的状态应该以参数的形式传送到 EJB 的方法中（并且通过使用一种机制如 HttpSession 来存储它）或者从持久性的后端存储（例如通过使用实体 bean)作为 EJB 事务的一部分来进行检索。在合适的情况下，这个信息可以缓存到内存中，但是要注意在分布式的环境中保存这种缓存所潜在的挑战性。缓存非常适合于只读数据。
避免使用有状态性不只是对 IBM/WebSphere 的建议，这是一个基本的 J2EE 设计原则。请参见 [Jewell]的 Tyler Jewell 对有状态 bean 的批评，其观点和上述的观点是相同的。
学习一下 J2EE 中的两阶段提交事务，并且使用这种方式，而不是开放您自己的事务管理。容器在事务优化方面几乎总是比较好的。
使用容器管理的事务（CMT）提供了两个关键的优势（如果没有容器支持这几乎是不可能的）：可组合的工作单元和健壮的事务行为。
只有在需要多种表示输出类型，并且输出类型被一个单一的控制器及后端支持时才使用 XML/XSLT。
10. 当使用 HttpSession 时，尽量只将当前事务所需要的状态保存其中，其他内容不要保存在 HttpSession 中。
启用会话持久性。HttpSessions 对于存储应用程序状态信息是非常有用的。其 API 易于使用和理解。遗憾的是，开发人员常常遗忘了 HttpSession 的目的——用来保持暂时的用户状态。它不是任意的数据缓存。我们已经见到过太多的系统为每个用户的会话放入了大量的数据（达到兆字节）。那好了，如果同时有 1000 个登录系统的用户，每个用户拥有 1MB 的会话数据，那么就需要 1G 或者更多的内存用于这些会话。要使这些 HTTP 会话数据较小一些，不然的话，您的应用程序的性能将会下降。一个大约比较合适的数据量应该是每个用户的会话数据在 2K-4K 之间，这不是一个硬性的规则，8K 仍然没有问题，但是显然会比 2K 时的速度要慢。一定要注意，不要使 HttpSession 变成数据堆积的场所。
一个常见的问题是使用 HttpSession 缓存一些很容易再创建的信息，如果有必要的话。由于会话是持久性的，进行不必要的序列化以及写入数据是一种很奢侈的决定。相反地，应该使用内存中的哈希表来缓存数据，并且在会话中保存一个对此数据进行引用的关键字。这样，如果不能成功登录到另外的应用服务器的话，就可以重新创建数据。（请参见 [Brown2]）
当谈及会话持久性时，不要忘记要启用这项功能。如果您没有启用会话持久性，或者服务器因为某种原因停止了（服务器故障或正常的维护），则所有此应用服务的当前用户的会话将会丢失。这是件令人非常不高兴的事情。用户不得不重新登录，并且重新做一些他们曾经已经做过的事情。相反地，如果启用了会话持久性，WebSphere 会自动将用户（以及他们的会话）移到另外一个应用服务器上去。用户甚至不知道会有这种事情的发生。我们曾经见到过一些产品系统因为存在于本地代码中令人难以忍受的 bug（不是 IBM 的代码！）而突然崩溃的情况，这这种情况下，上述功能仍然可以运行良好。
11. 在 WebSphere 中，使用动态缓存，并使用 WebSphere servlet 缓存机制.
通过使用这些功能，系统性能可以得到很大的提高，而开销是很小的。并且不影响编程模型。
通过缓存来提高性能的好处是众所周知的事情。遗憾的是，当前的 J2EE 规范没有包括一种用于 servlet/JSP 缓存的机制。然而，WebSphere 提供了对页面以及片断缓存的支持，这种支持是通过其动态缓存功能来实现的，并且不需要对应用程序作出任何改变。其缓存的策略是声明性的，而且其配置是通过 XML 配置描述符来实现的。因此，您的应用程序不会受到影响，并保持与 J2EE 规范的兼容性和移植性，同时还从 WebSphere 的 servlet 及 JSP 的缓存机制中得到性能的优化。
从 servet 及 JSP 的动态缓存机制得到的性能的提高是显而易见的，这取决于应用程序的特性。Cox 和 Martin [Cox]指出对一个现有的 RDF（资源描述格式）站点摘要 (RSS)servlet，当使用动态缓存时，其性能可以提高 10%。请注意这个实验只涉及到一个简单的 servlet，这个性能的增长量可能并不能反映一个复杂的应用程序。
为了更多地提高性能，将 WebSphere servlet/JSP 结果缓存与 WebSphere 插件 ESI Fragment 处理器、IBM HTTP Server Fast Response Cache Accelerator (FRCA) 和 Edge Server 缓存功能集成在一起。对于繁重的基于读取的工作负荷，通过使用这些功能可以得到许多额外的好处。（请参见 参考资料中的在 [Willenborg] 内描述的性能的提高）
12. 为了提高程序员的工作效率，将 CMP 实体 bean 作为 O/R 映射的首选解决方案.
通过 WebSphere 框架（readahead、缓存、隔离级别等）优化性能。如果可能，有选择的应用一些模式来达到提高性能的目的，例如 Fast-Lane 阅读器 [Marinescu]。
