我读得越多，我就越困惑。
请注意，所有问题都与服务和外观如何适应 MVC 模式有关。
我的理解是，Facade不是一个超级智能的对象，它只是一种暴露一个简单的接口/api来执行复杂操作的方法（例如：执行10美元的付款，这是一个涉及许多操作的复杂操作，但这种复杂性可以通过一个外观来处理，它只会以特定顺序调用相应的对象......等等...）
现在，服务是一种执行对多个DAO的调用以获得复杂数据结构的方法（我不太确定这一点，但这是我到目前为止所理解的）。
那么问题是，门面和服务有什么区别？在一天结束时，外观可以完美地访问多个DAO，以便通过提供简单的界面来执行复杂的操作，而服务似乎与此类似。
交易也是如此，我知道服务是开始交易的地方，但我同样觉得它们也可以放在立面上，毕竟，一个门面也可以调用几个DAO。
因此，哪个堆栈更有意义
控制器-立面-道控制器-服务-道
或者也许
controller-facadade-dao 有时 controller-façade-service-dao ？？
服务是将接口写入外部系统（如 LDAP 身份存储、支付网关或应用程序管理接口）的一种方式。这是一种概念性的方式，将外部系统视为有用服务的提供者，也许具有内部行为，而不是被动的块状操作。
外观是一种包装任何内容（包括服务）以将其很好地呈现给另一个组件的方式。外墙通常用于以下情况：
真正令人困惑的是，您可以（并且经常这样做）在一个或多个服务上创建外观。服务是组件实际访问资源的方式，外观是简化组件（如选项配置、连接等）的位。
如果你编写自己的 DAO，你可能会按照你需要的方式创建你的服务，所以编写一个外观是一个表明你做错了。如果 DAO 是由第三方构建的，并且比您的需求更复杂，那么您可以屏蔽该服务。
现在，服务是一种执行对多个DAO的调用以获得复杂数据结构的方法（我不太确定这一点，但这是我迄今为止所理解的）。
我会说DAO是一个自己的设计模式 - 参见维基百科。
如果我们将 DAO 与服务进行比较，我们得到：
...外观可以完美地访问多个DAO，以便通过提供简单的接口来执行复杂的操作，并且服务似乎类似。
一个立面可以包住DAO层，但我真的没有看到这种情况以一种有用的方式发生。最有可能的是，您需要一个API来访问对象的各个属性，遍历对象图和类似内容，而这正是DAO提供的。
交易也是如此，我知道服务是开始交易的地方......
当然可以，因为事务是由数据库和另一个组件或系统上提供的服务。
...但我同样觉得它们也可以放在立面上，毕竟，一个立面也可以调用几个DAO。
在许多方面，事务管理器服务是更复杂的后端实现的门面，在Web，应用程序，数据库和其他事务感知组件上协调事务。但是，这已经被事务服务实现抽象出来了。就我们用户而言，只有公共接口。
事实上，这就是这些设计模式的概念点 - 为用户提供适量的API，抽象出组件接口铁壁背后的实现的复杂性。
因此，哪个堆栈更有意义
控制器-立面-道控制器-服务-道
或者也许
controller-facadade-dao 有时 controller-façade-service-dao ？？
因此，正确答案是：
从字面上看，立面顾名思义，意味着建筑物的正面。走过马路的人只能看到立面，他们对里面的东西，布线，管道和其他复杂性一无所知。这张脸隐藏了建筑的所有复杂性，并展示了一张更简单友好的面孔。
在软件方面，façade通过提供更简单的界面隐藏了软件组件的复杂性，没有自己的功能，也不限制对substsyem的访问。常用于面向对象设计。SLF4J就是一个很好的例子 - 它是一个api，它是日志记录系统的简单外观，允许最终用户在部署时插入所需的日志记录系统。
服务是一个公共接口，它提供对功能单元的访问，并始终写入规范。它需要支持其不同使用者所需的通信协定（基于消息的通信、格式、协议、安全性、异常等）。有流程服务 - 业务工作流的封装，业务逻辑服务 - 规则/功能的封装，数据服务 - 与实体的交互，数据访问管理，基础设施服务 - 实用程序功能，如监控，日志记录和安全性。服务大多是可重用的、未关联的、松散耦合的功能单元。
它们非常相似，但取决于您如何看待它。
我看到的不同之处在于，立面是由内而外设计的。您可以查看子系统并设计外观以提供更简单的访问。服务由外向内设计。你看你的客户/客户定义一个合同并设计服务。
