会话外观核心 J2EE 模式的优点和缺点是什么？
会话外观核心 J2EE 模式的优点和缺点是什么？
其背后的假设是什么？
这些假设在特定环境中有效吗？
What are the advantages and disadvantages of the Session Façade Core J2EE Pattern?
What are the assumptions behind it?
Are these assumptions valid in a particular environment?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
会话外观是一种奇妙的模式 - 它实际上是业务外观模式的特定版本。 这个想法是将业务功能绑定到离散的包中 - 例如 TransferMoney()、Withdraw()、Deposit()...这样您的 UI 代码就可以根据业务操作来访问事物，而不是低级别的数据访问或其他细节它不应该关心。
特别是对于会话外观 - 您使用会话 EJB 充当业务外观 - 这很好，因为这样您就可以利用所有 J2EE 服务（身份验证/授权、事务等）...
希望有帮助...
Session Facade is a fantastic pattern - it is really a specific version of the Business Facade pattern. The idea is to tie up business functionality into discrete bundles - such as TransferMoney(), Withdraw(), Deposit()... So that your UI code is accessing things in terms of business operations instead of low level data access or other details that it shouldn't have to be concerned with.
Specifically with the Session Facade - you use a Session EJB to act as the business facade - which is nice cause then you can take advantage of all the J2EE services (authentication/authorization, transactions, etc)...
Hope that helps...
Session Facade 模式的主要优点是您可以根据业务功能将 J2EE 应用程序划分为逻辑组。 会话外观将由 POJO 从 UI（即业务代表）调用，并引用适当的数据访问对象。 例如，PersonSessionFacade 将由 PersonBusinessDelegate 调用，然后它可以调用 PersonDAO。 PersonSessionFacade 上的方法至少将遵循 CRUD 模式（创建、检索、更新和删除）。
通常，大多数会话外观都是作为无状态会话 EJB 实现的。 或者，如果您在 Spring 中使用 AOP 进行事务，则可以创建一个服务 POJO，它可以是事务管理器的所有连接点。
SessionFacade 模式的另一个优点是任何具有一点经验的 J2EE 开发人员都会立即理解您。
SessionFacade 模式的缺点：它假定一个特定的企业架构，该架构受到 J2EE 1.4 规范的限制（有关这些批评，请参阅 Rod Johnson 的书籍）。 最具破坏性的缺点是它比必要的更复杂。 在大多数企业 Web 应用程序中，您需要一个 servlet 容器，并且 Web 应用程序中的大部分压力将集中在处理 HttpRequest 或数据库访问的层。 因此，将 servlet 容器部署在与 EJB 容器不同的进程空间中似乎并不值得。 即，对 EJB 的远程调用弊大于利。
The main advantage of the Session Facade pattern is that you can divide up a J2EE application into logical groups by business functionality. A Session Facade will be called by a POJO from the UI (i.e. a Business Delegate), and have references to appropriate Data Access Objects. E.g. a PersonSessionFacade would be called by the PersonBusinessDelegate and then it could call the PersonDAO. The methods on the PersonSessionFacade will, at the very least, follow the CRUD pattern (Create, Retrieve, Update and Delete).
Typically, most Session Facades are implemented as stateless session EJBs. Or if you're in Spring land using AOP for transactions, you can create a service POJO that which can be all the join points for your transaction manager.
Another advantage of the SessionFacade pattern is that any J2EE developer with a modicum of experience will immediately understand you.
Disadvantages of the SessionFacade pattern: it assumes a specific enterprise architecture that is constrained by the limits of the J2EE 1.4 specification (see Rod Johnson's books for these criticisms). The most damaging disadvantage is that it is more complicated than necessary. In most enterprise web applications, you'll need a servlet container, and most of the stress in a web application will be at the tier that handles HttpRequests or database access. Consequently, it doesn't seem worthwhile to deploy the servlet container in a separate process space from the EJB container. I.e. remote calls to EJBs create more pain than gain.
Rod Johnson 声称您想要使用会话外观的主要原因是您正在执行容器管理的事务 - 这对于更现代的框架（如 Spring）来说是不必要的。
他说，如果您有业务逻辑 - 将它在 POJO 中。 （我同意这一点 - 我认为这是一种更加面向对象的方法 - 而不是实现会话 EJB。）
http://forum.springframework.org/showthread.php?t=18155
很高兴听到相反的论点。
Rod Johnson claims that the main reason you'd want to use a Session Facade is if you're doing container managed transactions - which aren't necessary with more modern frameworks (like Spring.)
He says that if you have business logic - put it in the POJO. (Which I agree with - I think its a more object-oriented approach - rather than implementing a session EJB.)
http://forum.springframework.org/showthread.php?t=18155
Happy to hear contrasting arguments.
似乎每当您谈论任何与 J2EE 相关的事情时，幕后总是存在一大堆假设，人们以这种或那种方式假设这些假设，这会导致混乱。 （我可能也可以让问题更清楚。）
假设 (a) 我们希望通过 EJB 规范严格意义上使用容器管理的事务，那么
会话外观是一个好主意 - 因为它们将低级数据库事务抽象为能够提供更高级别的应用程序事务管理。
假设 (b) 您指的是会话外观的一般架构概念 - 那么
解耦服务和消费者并在此之上提供友好的界面是一个好主意。 计算机科学通过“添加额外的间接层”解决了许多问题。
Rod Johnson 写道：“具有远程接口的 SLSB 为基于 RMI 构建的分布式应用程序提供了非常好的解决方案。然而，这只是少数需求。经验表明，除非需求强迫，否则我们不想使用分布式架构。我们仍然可以如有必要，可以通过在良好的共置对象模型之上实现远程外观来为远程客户端提供服务。” （Johnson，R“没有 EJB 的 J2EE 开发”第 119 页。）
假设 (c) 您认为 EJB 规范（特别是会话外观组件）是良好设计景观中的一个污点：
Rod Johnson 写道
“一般来说，在 Spring 应用程序中使用本地 SLSB 的原因并不多，因为 Spring 提供了比 EJB 更强大的声明性事务管理，并且 CMT 通常是使用本地 SLSB 的主要动机。因此，您可能不需要” http://forum.springframework.org/showthread.php ?t=18155
在 Web 服务器的性能和可扩展性是主要关注点的环境中 - 并且成本是一个问题 - 那么会话外观架构看起来不太有吸引力 - 直接与数据库对话可能会更简单（尽管这更多的是关于分层。）
It seems that whenever you talk about anything J2EE related - there are always a whole bunch of assumptions behind the scenes - which people assume one way or the other - which then leads to confusion. (I probably could have made the question clearer too.)
Assuming (a) we want to use container managed transactions in a strict sense through the EJB specification then
Session facades are a good idea - because they abstract away the low-level database transactions to be able to provide higher level application transaction management.
Assuming (b) that you mean the general architectural concept of the session façade - then
Decoupling services and consumers and providing a friendly interface over the top of this is a good idea. Computer science has solved lots of problems by 'adding an additional layer of indirection'.
Rod Johnson writes "SLSBs with remote interfaces provide a very good solution for distributed applications built over RMI. However, this is a minority requirement. Experience has shown that we don't want to use distributed architecture unless forced to by requirements. We can still service remote clients if necessary by implementing a remoting façade on top of a good co-located object model." (Johnson, R "J2EE Development without EJB" p119.)
Assuming (c) that you consider the EJB specification (and in particular the session façade component) to be a blight on the landscape of good design then:
Rod Johnson writes
"In general, there are not many reasons you would use a local SLSB at all in a Spring application, as Spring provides more capable declarative transaction management than EJB, and CMT is normally the main motivation for using local SLSBs. So you might not need th EJB layer at all. " http://forum.springframework.org/showthread.php?t=18155
In an environment where performance and scalability of the web server are the primary concerns - and cost is an issue - then the session facade architecture looks less attractive - it can be simpler to talk directly to the datbase (although this is more about tiering.)