【发布时间】：2010-09-10 11:17:36
【问题描述】：
Session Façade Core J2EE 模式的优点和缺点是什么？
它背后的假设是什么？
这些假设在特定环境中是否有效？
【问题讨论】：
标签： session jakarta-ee design-patterns facade
【发布时间】：2010-09-10 11:17:36
【问题描述】：
会话外观是一种奇妙的模式——它实际上是业务外观模式的一个特定版本。这个想法是将业务功能绑定到离散的捆绑包中 - 例如 TransferMoney()、Withdraw()、Deposit()... 这样您的 UI 代码就可以根据业务操作而不是低级别的数据访问或其他细节来访问事物它不应该担心。
特别是会话外观 - 您使用会话 EJB 作为业务外观 - 这是很好的原因，您可以利用所有 J2EE 服务（身份验证/授权、事务等）...
希望对您有所帮助...
【讨论】：
会话外观模式的主要优点是您可以将 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 容器不同的进程空间中。 IE。对 EJB 的远程调用带来的痛苦多于收获。
【讨论】：
Rod Johnson 声称，您想要使用 Session Facade 的主要原因是，如果您正在执行容器管理的事务 - 这对于更现代的框架（如 Spring）来说是不必要的。
他说如果你有业务逻辑 - 把它放在 POJO 中。 （我同意——我认为它是一种更面向对象的方法——而不是实现会话 EJB。） http://forum.springframework.org/showthread.php?t=18155
很高兴听到对比鲜明的论点。
【讨论】：
似乎每当您谈论任何与 J2EE 相关的事情时——在幕后总是有一大堆假设——人们以一种或另一种方式假设——这会导致混乱。 （我可能也可以让问题更清楚。）
假设 (a) 我们想通过 EJB 规范严格意义上使用容器管理事务
会话外观是一个好主意 - 因为它们抽象出低级别的数据库事务，以便能够提供更高级别的应用程序事务管理。
假设 (b) 您指的是会话外观的一般架构概念 - 那么
将服务和消费者解耦并在此之上提供一个友好的界面是一个好主意。计算机科学通过“添加额外的间接层”解决了许多问题。
Rod Johnson 写道：“具有远程接口的 SLSB 为基于 RMI 构建的分布式应用程序提供了一个非常好的解决方案。但是，这是少数要求。经验表明，除非有需求，否则我们不想使用分布式架构。如有必要，我们仍然可以通过在良好的协同定位对象模型之上实现远程处理外观来为远程客户端提供服务。” （Johnson, R“没有 EJB 的 J2EE 开发”第 119 页。）
假设 (c) 您认为 EJB 规范（尤其是会话外观组件）是良好设计领域的一大败笔：
罗德·约翰逊写道 “一般来说，在 Spring 应用程序中使用本地 SLSB 的原因并不多，因为 Spring 提供了比 EJB 更强大的声明式事务管理，而 CMT 通常是使用本地 SLSB 的主要动机。所以你可能不需要第 EJB 层。" http://forum.springframework.org/showthread.php?t=18155
在网络服务器的性能和可扩展性是主要关注点的环境中 - 并且成本是一个问题 - 然后会话外观架构看起来不那么有吸引力 - 直接与数据库对话可能更简单（尽管这更多是关于分层。）
【讨论】：