Java 是服务和faç的角色；相似吗？

我读得越多，就越困惑

请注意，所有的问题都与服务和外观如何适应MVC模式有关

我的理解是，Facade不是一个超级智能对象，它只是一种公开简单接口/api以执行复杂操作的方法（例如：执行一个10美元的支付，这是一个涉及许多操作的复杂操作，但是这种复杂性可以由一个facade来处理，facade只会以特定的顺序调用相应的对象……等等。）

现在，服务是一种执行对多个DAO的调用以获得复杂数据结构的方法（我不太确定这一点，但这是我目前所了解的）

那么，问题是，facade和服务之间有什么区别？最终，facade可以通过提供简单的接口完美地访问多个DAO，以便执行复杂的操作，而服务似乎与之类似

事务也是如此，我知道服务是开始事务的地方，但我同样认为它们也可以放在外观上，毕竟，外观也可以调用多个DAO

那么哪个堆栈更有意义呢

控制器外观dao 控制器服务dao

或许

---

控制器facadade dao，有时控制器facadade服务dao？？？

通常这些术语仅在其特定上下文中使用

• “Facade”常用上下文：用于应用程序复杂部分（如第三方libs）的简单API

• “服务”上下文：解锁和显示系统中的业务实体。（SOA、DAO、安全性等）

---

您可以将模式视为一种不断发展的语言。它似乎从来都不是完美的。每个模式都有自己的历史和上下文。有时类可以同时视为服务和外观，有时则不是

例如：使用术语“服务”调用第三方API可能被视为滥用，因为上下文错误。

服务接口通常代表业务问题：执行某些操作和/或获取一些信息。对于服务提供商来说，将其服务作为内部后端服务的门面来实现是合理的——您永远不会看到这一点

您的外观可能会包装一些通用接口，其中可能包括服务接口

例如，您可能有一个银行账户的服务接口（操作：银行转账），以及一个本地会计记录的本地API（I转账）。您可能会引入一个带有“移动资金”的外观使用银行服务接口并管理本地支票簿的操作。

服务是将接口写入外部系统的一种方式，如LDAP标识存储、支付网关或应用程序管理接口。它是将外部系统视为有用服务提供商的一种概念性方式与内部行为，而不是被动的肿块进行手术

facade是一种包装任何东西（包括服务）的方式，可以很好地将其呈现给另一个组件。facade通常在以下情况下使用：

• 库或组件很复杂，应用程序只需要其中的一个子集。Facade向应用程序提供简化的API
• 您正在使用多个库或组件，需要将它们统一起来，向应用程序提供一个统一的API
• 您正在使用的库具有复杂的设置或一组依赖项，facade将所有这些都封装在应用程序的上下文中

真正令人困惑的是，您可以（并且经常这样做）在一个或多个服务上创建门面。服务是组件实际访问资源的方式，门面是简化组件的位（例如选项配置、连接等）

如果您编写自己的DAO，您可能会按照自己的需要创建服务，因此编写facade表明您做得不对。如果DAO是由第三方构建的，并且比您的需要更复杂，那么您可以将服务facade

现在，服务是一种执行对多个DAO的调用以获得复杂数据结构的方法（我不太确定这一点，但这是我迄今为止所了解的）

我想说，DAO是一种设计模式，它本身就是一种设计模式

如果我们将DAO与服务进行对比，我们有：

• API级别：
  • DAO：对属性的细粒度访问
  • 服务：对服务的粗粒度访问
• 在实施方面：
  • DAO：主要在客户机上，但在数据库中存储数据（无行为）
  • 服务：主要在服务器上
• 如何调用接口
  • DAO：客户端直接绑定到同一命名空间和JVM中的对象
  • 服务：客户端只是网络、跨vm或跨命名空间操作的存根

…facade可以完美地访问多个DAO，以便通过提供简单的接口执行复杂的操作，而服务似乎与之类似

facade可以封装DAO层，但我并不认为这是一种有用的方式。很可能您需要一个API来访问对象的各个属性、遍历对象图和类似的内容，而这正是DAO所提供的

事务也是如此，我知道服务是开始事务的地方

当然，因为事务是由数据库和其他组件或系统提供的服务

…但我同样认为，它们也可以放在正面，毕竟，正面也可以称为多个DAO

在许多方面，事务管理器服务是一个更加复杂的后端实现的门面，协调