服务门面（根据Adam Bien） - EJB 3

Question

我读过Adam Bien Rethinking Business tier。它提到了创建服务外观，例如OrderService。但是，您可以为大型企业应用程序提供许多服务外观。我有客户模块，订单模块，运输模块，我可以为每个高级模块创建服务外观，而不是创建包含所有这些模块的大型外观。所以在我的JSF 2.0网络应用程序中，我可以拨打电话： transportationServiceFacade.findDetails（） orderServiceFacade.findDetails（）

而不是这样做

genericServiceFacade.findDetails（）

我更喜欢在我的例子中使用许多外观。这会影响性能吗？

Answer 1

你当然可以。我不知道这本书，但我知道Adam Bien是一位简约而优雅的实用者。我认为这很棒，特别是如果你与EJB 2.x天内完成的Enterprise Java解决方案进行比较。但他采用的简单性有时也会过于简单化。正如您可能已经意识到的那样，随着您的系统的发展，将通用外观拆分为更专业的外墙会更有意义。

这肯定不会影响性能，因为这些EJB也将被轮询。如果有的话，你会消耗更多的内存，但我不担心这一点，因为通常最好先关注你的架构，然后再考虑性能。即便如此，性能不应该是“我认为”，而是“我知道”（即：测量，并向自己证明某些事情确实影响了性能）。

Answer 2

ServiceFacase只是一种模式，您可以根据需要对其进行修改。但是，ServiceFacade模式的想法是将单个组件的边界方法分组为一个单独的类 - 服务外观。如果您需要更多单独的服务外观，您可能还需要更多的分离组件。

另一个建议是，如果你从前端的单一动作调用两个不同立面的方法，最好将其中的业务逻辑分组为其中一个立面中的单个方法。服务外观应始终启动事务，最好减少一个操作中的事务数，最好是单个事务。服务外观应该设计为满足客户从外部访问组件而不是其他任何内容的需求。

Answer 3

根据亚当·比恩（Adam's Bien）的“现实世界Java EE模式。重新思考最佳实践”（2012年），当边界变得肿且内聚时，服务门面或控制是对复杂服务层的可选分解。

如今，我们可能会在Web层（资源，控制器，REST API前端层）遭受逻辑过于复杂的困扰，这可能包括合并多个服务的结果。就控制（服务外观）模式而言，那些将是重构的良好候选者，这将改善可维护性并关注问题的分离。您还将获得免费的测试简便性。