我读过 Adam Bien Rethinking Business tier。它提到了创建一个服务外观，例如 OrderService。但是，您能否为大型企业应用程序提供许多服务外观。我有客户模块、订单模块、运输模块，我可以为每个高级模块创建一个服务外观，而不是创建一个包含所有这些模块的大外观。因此，在我的 JSF 2.0 Web 应用程序中，我可以拨打如下电话： transportServiceFacade.findDetails() orderServiceFacade.findDetails()
不要这样做
genericServiceFacade.findDetails()
在我的示例中，我宁愿使用许多外观。这会影响性能吗？
【问题讨论】：
标签： service ejb-3.0 java-ee-6 facade
你当然可以。我不知道这本书，但我知道 Adam Bien 是一位简约和优雅的实践者。我认为这很棒，特别是如果您将其与 EJB 2.x 时代完成的 Enterprise Java 解决方案进行比较。但他采用的简单性有时也过于简单化了。您可能会意识到，随着系统的增长，将通用外观拆分为其他更专业的外观会更有意义。
这当然不会影响性能，因为这些 EJB 也会被轮询。如果有的话，你会消耗更多的内存，但我不会担心这一点，因为通常最好先关心你的架构，然后再关心性能。即使那样，性能也不应该是“我认为”的事情，而是“我知道”（即：衡量并向自己证明某些东西确实在影响性能）。
【讨论】：
ServiceFacase 只是一种模式，您可以根据需要对其进行修改。然而，ServiceFacade 模式的思想是将单个组件的边界方法组合成一个类——服务门面。如果您需要更多独立的服务外观，那么您可能还需要更多解耦的组件。
另一个建议是，如果您从前端的单个操作调用两个不同外观的方法，最好将该业务逻辑分组到其中一个外观中的单个方法中。服务门面应该总是启动事务，最好在一个操作中减少事务的数量，最好是单个事务。服务外观的设计应该满足客户端从外部而不是通过其他任何方式访问组件的需求。
【讨论】：
根据 Adam 的 Bien“Real World Java EE Patterns. Rethinking Best Practices”（2012 年），当边界变得臃肿和内聚时，服务外观或控制是复杂服务层的可选分解。
如今，我们可能会遭受 Web 层（资源、控制器、REST API 前端）过于复杂的逻辑，这可能包括来自多个服务的结果的组合。这些将是根据控制（服务外观）模式进行重构的良好候选者，这将提高可维护性并遵循关注点分离。您还可以轻松地进行免费测试。
【讨论】：