EJB 最佳实践:业务委派模式 | ![]() | 英文原文 | ![]() | |
![]() | ||||
![]() |
![]() |
Brett McLaughlin(brett@oreilly.com)
如果您从一开始就一直在学习本系列文章,那么您就知道我们一直关心的问题之一是将应用和表示逻辑与业务逻辑分隔开。例如,在第一篇技巧文章中,我们重点讨论远程对象设计的难题,特别是将 bean 的实现与其接口分隔时出现的难题。我们用业务接口模式解决了这个难题,本文中我们将再次使用这个模式。上一篇技巧文章解决了在支持用户访问实体 bean 内包含的数据的同时,又要避免那些 bean 直接暴露给应用层这两种需求之间的冲突。 在这两个例子中,通过从使用业务逻辑的代码中谨慎地抽象出业务逻辑实现来解决核心问题。正如本技巧文章将演示的,那种抽象是良好的应用程序设计的基础之一,特别是对于基于 EJB 的应用程序设计。这里,我们将再次使用业务接口模式和会话 bean 来使您的 Web 层与 Enterprise JavaBeans 组件保持松散耦合。 业务接口模式我们以前的业务接口模式的实现允许我们提供特定于业务的接口,用于与会话 bean 交互。清单 1 显示了那个接口,在本技巧文章中我们将再次使用这个接口:
注:Library 接口不包含任何 EJB 语义。而是将所有的实现和 EJB 细节都在实现该接口的会话 bean 内处理。现在,让我们查看一下企业应用程序的 Web 层可以如何访问 Library 接口和支持它的会话 bean:
清单 2 使用了另一个类,如果您从本系列一开始就学习的话,您应该熟悉这个类。通过查询 上述代码还不错 — 比起装入 JNDI 初始上下文、手工获得 home 接口,随后直接处理实体 bean,它确实有了改进。但它确实包含了一个基本的缺点:Web 层仍旧与 EJB 组件结合在一起,尤其与 获得“中间人”:业务委派模式
在
通过引入 在下一篇系列文章中,我们将详述业务委派模式的使用,进而使它更通用化。由此产生的结果将是获得更佳的代码,以及与 EJB 技术更少的相关性。
| ![]() |