[转载]EJB 倡导者: 什么是最佳实践？

EJB 倡导者: 什么是最佳实践？

在本文中，我们首先通过读者提出的问题解释了“最佳实践”的整体理念，接着介绍了有关应用程序体系结构的新知识，最后说明了 Enterprise JavaBeans™ 这一强大概念尚未得到大家广泛采用的原因。

摘自 IBM WebSphere 开发者技术期刊。

在每个专栏中，EJB 倡导者都采用独特的前后衔接的对话方式与实际客户和开发人员进行交流，并在期间针对某一大家关注的设计问题推荐解决方案。其中并没有介绍任何确定性的细节，也没有提出“新颖的”或专有的体系结构。有关详细信息，请参见 EJB 倡导者简介。

很多人不相信“最佳”这一理念

亲爱的 EJB 倡导者：

不客气地说，我不相信“最佳”实践这一理念。您自己在第一篇文章 中说，“没有不好的模式，只有不好的模式应用。”难道最佳实践仅仅是说说而已？

署名：
For Better or For Worse

回页首

最佳总是相对于某个问题和上下文而言的

亲爱的 For Better or For Worse：

感谢您就最佳理念提出的看法和问题。我表示非常理解。在这些讨论中，我发现很多人对“最佳”一词颇为不满，因为这个词显示出高人一等的优越感，就如同说我的实践比任何其他人的都要好一样。

事实上，这远非我之本意。最佳并非要拿“您”的实践与“我”的实践进行比较，而是针对一组需求对两种以上用于解决某个问题的方法所进行的比较。

例如，我们来看人们最早使用的策略之一：

"分而治之"

这一简单的语句运用了两种方法来解决一个问题：a) “分解”和 b) “解决”。但是您不会问到底是“分解”好还是“解决”好。真正的问题在于，何时停止分解而开始解决最佳。最佳实践的目的就是描述每种方法的最佳应用时机。因此，在这种情况下，对这一策略的“更好”（更完整地描述）措词可能是这样的：

"问题复杂时就分解，问题简单时就解决".

这句话意味着将两种方法运用于解决同一复杂问题，因为最终可以将复杂问题分解为足够简单的子问题。当然，您也可以先不进行分解而直接“解决”一个简单的问题。下图更清楚地说明了最佳实践的迭代（及常见的并行）特性。它将问题视为棱形，而将运用的解决方法视为矩形。连接问题和方法的弧线上的标签描述了在给定决策点上使用不同于其他方法的某一方法的原因：

进一步说，哪一种是最佳的呢，是无状态会话 Bean、有状态会话 Bean、实体 Bean，还是消息驱动 Bean？当然，答案要依赖于具体应用的需求。是需要立即响应，还是只需“即发即弃 (Fire and Forget)”请求？如果需要立即响应，那么是否需要“记住”请求发送的顺序或者要求请求间没有相互依赖性呢？针对这些需求，EJB 组件集能够客观地进行比较，从而找到针对实际应用情况的最佳方案。但是偶尔也会遇到某个复杂企业应用需要用到所有这些组件的情况。

还有一点需要强调的是：所谓的最佳是飘忽不定的。由于情况的不同，例如语言和平台在不断地发生变化，因此针对所要解决的问题而提出的最佳实践也会经常改变。EJB 倡导者的上一篇文章详细地比较了 EJB 3 规范与目前的规范，您可以根据这些规范来考虑问题，从而找到一个折衷的方案。

针对实际企业需求探索如何最好地使用 EJB 组件是本 EJB 倡导者系列的真正目的。

希望这对您有所帮助。

好的，就先到此为止，
您的 EJB 倡导者

回页首

如何对待不断变化的最佳实践？

亲爱的 EJB 倡导者：

非常感谢您花时间阐明最佳实践的意义。我也认为将其称为最佳听起来有些傲慢自大，而且我非常赞同将最佳实践看作针对具体问题简单地将一种方法与另一种方法进行比较这一理念。

但是，您最后关于情况变化的观点引出了一个有趣的话题：既然 EJB 规范也在不断改变，为何我们还要费尽周折学习关于 EJB 2 组件的最佳实践？此外，我还担心一个问题，EJB 3 是否将存在足够长的时间，谁能够给我保证？

谢谢。
For Better or For Worse

回页首

关注通用设计原则和要求

亲爱的 For Better or For Worse：

诚然，事物不断地发生改变让人感到灰心，但是既然您和 EJB 倡导者一样都经历了过去的 COBOL 时代，那么您会意识到下面这句谚语背后的真义：“三十年河东，三十年河西。”还有一句对老手不会起什么安慰作用的格言是“江山易改，本性难移”（如果我以前用过这句格言，请您谅解）。

很抱歉使用这些民谚。我的观点是，当今的企业应用遇到的大多数问题与我们以往遇到的问题是相同的。计算机的运算速度永远不够快，内存或硬盘永远不够用，屏幕也永远不够大。因此，大多数用于构建解决方案的最佳实践都是相同的。

例如，今天用于设计“瘦客户端”应用的最佳实践与二十年前的最佳实践基本相同。主要的不同之处在于，屏幕不再是“绿颜色”的（并且并不仅有文本）。除了语言与平台的差异外，通用设计原则是相同的：将用于屏幕呈现的逻辑（“视图”）与获取和/设置数据的函数中的逻辑（“模型”）相分离。

下面是另一个示例。在 EJB 2 规范之前，总是认为在实体 Bean 周围使用会话 Bean Facade 是最佳的。有了 EJB 2 之后，“Home”实体可用于相同的目的——当存在一个代表用户角色的实体时，便不再需要额外的会话 Bean 组件。无论如何，常用的最佳实践是避免直接将持久层公开给客户，而应提供一个 Facade 来代替。创建 Facade 的细节可能会发生改变，但使用它一定是最佳实践，这适用于任何您能想象到的语言和平台――甚至是 COBOL CICS 应用！

这些示例说明，只要您能够首先关注通用设计原则，然后再考虑如何在某一平台上实现此原则的细节，就不会误入歧途。我忍不住想起了另一句古谚。获得最佳实践的方法就是应用策略：

"功能决定形式"

换言之，学习有关最佳实践的知识（即使是旧知识）总是值得的，因为每种方法的背后都隐含一条通用原则，这有助于您满足特定的需求。通常仅需要对需求的某一方面进行抽象（如用户不得不使用的平台和语言）。

Java Enterprise Edition (JEE) 规范之所以重要，是因为发明者们充分考虑到与企业应用相关的需求。不仅是功能部分，而且包括非功能部分，如可靠性、可用性、效率、可维护性及可移植性。在每个组件和 API 背后都隐含一条通用设计原则，这使得该组件能够最好地应用于满足这些需求。在本系列中，我们已经研究了许多这样的原则，例如，EJB 组件如何将业务逻辑与提供本地或远程部署、安全、事务、持久化及异步调用相分离。此外，如果您还还记得，Java 是一种与平台无关、“编写一次，到处运行”的语言，有助于与其他语言编写的组件集成，那么对于构建实际的企业级应用，您还有什么要求呢？

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/374079/viewspace-130321/，如需转载，请注明出处，否则将追究法律责任。