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

Question

我读过Adam Bien重新思考业务层。它提到了创建服务门面，例如OrderService。但是，您是否可以为大型企业应用程序提供许多服务门面。我有客户模块，订单模块，运输模块，我可以为每个高级模块创建一个服务外观，而不是创建一个包含所有这些模块的大外观。所以在我的JSF 2.0 web应用程序，我可以作出这样一个电话： transportationServiceFacade.findDetails（） orderServiceFacade.findDetails（）

，而不是做这种方式

genericServiceFacade.findDetails（）

我而在我的例子中使用了许多外墙。这会影响性能吗？

Answer 1

你当然可以。我不知道这本具体的书，但我知道Adam Bien是一位简单而优雅的执业者。我认为这很好，特别是如果您与在EJB 2.x时期完成的Enterprise Java解决方案进行比较。但他所采用的简单也有时会过于简单化。正如你可能意识到的那样，随着你的系统的增长，把一个通用外观分成更加专业化的其他外墙更有意义。

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

Answer 2

ServiceFacase只是一种模式，您可以将其修改为套件您的需要。然而，ServiceFacade模式的想法是将单个组件的边界方法组合成一个单一的类 - 服务门面。如果您需要更多独立的服务外观，那么您也有可能需要更多的解耦组件。


另一个建议是，如果您在前端对单个动作调用两个不同外观的方法，最好将该业务逻辑组合到一个外观中的单个方法中。服务外观应始终启动事务，最好减少一个操作中的事务数量，理想情况下为单个事务。服务门面应该设计用于客户从外部访问组件的需求，而不是其他任何事情。