8

会话外观核心 J2EE 模式的优点和缺点是什么？

它背后的假设是什么？

这些假设在特定环境中是否有效？

4

4 回答 4

6

Session Facade 是一种奇妙的模式——它实际上是 Business Facade 模式的一个特定版本。这个想法是将业务功能绑定到离散的捆绑包中 - 例如 TransferMoney()、Withdraw()、Deposit()... 这样您的 UI 代码就可以根据业务操作而不是低级别的数据访问或其他细节来访问事物它不应该担心。

特别是会话外观——您使用会话 EJB 作为业务外观——这是很好的原因，您可以利用所有 J2EE 服务（身份验证/授权、事务等）...

希望有帮助...

于 2008-09-18T00:13:43.530 回答
0

会话外观模式的主要优点是您可以将 J2EE 应用程序按业务功能划分为逻辑组。会话外观将由 UI 中的 POJO（即业务委托）调用，并具有对适当数据访问对象的引用。例如 PersonSessionFacade 将由 PersonBusinessDelegate 调用，然后它可以调用 PersonDAO。PersonSessionFacade 上的方法至少会遵循 CRUD 模式（创建、检索、更新和删除）。

通常，大多数会话外观都是作为无状态会话 EJB 实现的。或者，如果您在 Spring 领域使用 AOP 进行事务，则可以创建一个服务 POJO，它可以作为事务管理器的所有连接点。

SessionFacade 模式的另一个优点是任何具有一点经验的 J2EE 开发人员都会立即了解您。

SessionFacade 模式的缺点：它假定特定的企业架构受到 J2EE 1.4 规范的限制（有关这些批评，请参阅 Rod Johnson 的书籍）。最具破坏性的缺点是它比必要的复杂。在大多数企业Web应用程序中，您将需要一个 servlet 容器，而 Web 应用程序中的大部分压力将在处理 HttpRequest 或数据库访问的层上。因此，似乎不值得将 servlet 容器部署在与 EJB 容器不同的进程空间中。即对 EJB 的远程调用带来的痛苦多于收获。

于 2008-09-18T23:16:40.163 回答
0

Rod Johnson 声称您想要使用 Session Facade 的主要原因是如果您正在执行容器管理的事务 - 这对于更现代的框架（如 Spring）是不必要的。

他说，如果你有业务逻辑 - 把它放在 POJO 中。（我同意 - 我认为它是一种更面向对象的方法 - 而不是实现会话 EJB。） http://forum.springframework.org/showthread.php?t=18155

很高兴听到相反的论点。

于 2008-09-21T23:31:47.797 回答
0

似乎每当您谈论任何与 J2EE 相关的事情时——在幕后总是有一大堆假设——人们以一种或另一种方式假设——然后导致混乱。（我可能也可以使问题更清楚。）

假设 (a) 我们想通过 EJB 规范严格地使用容器管理事务，那么

会话外观是一个好主意——因为它们抽象出低级别的数据库事务，以便能够提供更高级别的应用程序事务管理。

假设 (b) 您的意思是会话外观的一般架构概念 - 那么

将服务和消费者解耦并在此之上提供一个友好的界面是一个好主意。计算机科学通过“添加额外的间接层”解决了许多问题。

Rod Johnson 写道：“具有远程接口的 SLSB 为基于 RMI 构建的分布式应用程序提供了一个非常好的解决方案。然而，这是少数要求。经验表明，除非有需求，否则我们不想使用分布式架构。我们仍然可以如有必要，通过在良好的协同定位对象模型之上实现远程处理外观来为远程客户端提供服务。” （Johnson, R“没有 EJB 的 J2EE 开发”p119。）

假设 (c) 您认为 EJB 规范（尤其是会话外观组件）是对良好设计领域的破坏，那么：

Rod Johnson 写道：“总的来说，在 Spring 应用程序中使用本地 SLSB 的理由并不多，因为 Spring 提供了比 EJB 更强大的声明式事务管理，而 CMT 通常是使用本地 SLSB 的主要动机。所以你可能根本不需要 EJB 层。” http://forum.springframework.org/showthread.php?t=18155

在 Web 服务器的性能和可扩展性是主要关注点的环境中 - 并且成本是一个问题 - 然后会话外观架构看起来不那么有吸引力 - 直接与数据库对话可能更简单（尽管这更多地是关于分层。）

于 2008-09-22T02:06:01.093 回答