问服务和立面的角色相似吗？

EN

服务是一种向外部系统编写接口的方式，例如LDAP身份存储、支付网关或应用程序管理接口。这是一种概念性的方法，将外部系统视为有用服务的提供者，可能具有内部行为，而不是要操作的被动块。

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

• 库或组件很复杂，您的应用程序只需要它的一个子集。您的外观将简化的API呈现给使用了几个库或组件的application
• You，并且需要统一它们，向您正在使用的application
• The库呈现统一的API需要一个复杂的设置或一组依赖项，并且Facade将所有这些都包装在您的应用程序的上下文中。

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

如果您编写自己的DAO，您可能会根据需要创建您的服务，因此编写facade表明您做错了。如果DAO是由第三方构建的，并且比您的需求更复杂，那么您可以对服务进行外观处理。

现在，服务是一种对多个DAO执行调用以获得复杂数据结构的方法(我对此不太确定，但这是我到目前为止所理解的)。

我想说DAO是一种完全独立的设计模式-- see wikipedia。

如果我们将DAO与服务进行比较，我们会得到：

对properties

• Service:的细粒度访问粗粒度对services

的访问：

• 级别的
  • DAO

​

实现所在的

• ：
  • DAO:主要在客户端，但在database
  • Service:中存储数据(无行为)主要在server

上

​

• 如何调用JVM DAO接口:客户端直接绑定到相同名称空间和
  • 服务中的对象:客户端只是网络、跨vm或跨名称空间服务的存根

​

...facade可以完美地访问多个DAO，以便通过提供一个简单的接口来执行复杂的操作，并且服务看起来类似于某些东西。

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

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

当然可以，因为事务是由数据库和另一个组件或系统提供的服务

...但我同样觉得它们也可以放在facade上，毕竟一个facade也可以调用多个DAO。

在许多方面，事务管理器服务是复杂得多的后端实现的门面，协调web、应用程序、数据库和其他事务感知组件上的事务。然而，这已经被事务服务实现抽象出来了。就我们用户而言，只有公共接口。

事实上，这是这些设计模式的概念点-为用户提供适量的API，抽象出组件接口铁墙后面实现的复杂性。

，因此哪个堆栈更有意义

控制器-门面-道控制器-服务-道

或者也许

controller-facadade-dao，有时是controller-facade-service-dao ?？

1. DAO是对数据库的一种服务，但实际上DAO本身就是一种设计模式。
2. 如果您编写自己的DAO，则永远不需要facade。

因此，正确的答案是：

• 控制器- dao

从字面上看，立面顾名思义就是指建筑物的正面。路过这条路的人只能看到立面，他们不知道里面是什么，布线，管道和其他复杂情况。这张脸隐藏了建筑的所有复杂性，并显示出一张更简单、友好的脸。

在软件方面，facade通过提供更简单的界面隐藏了软件组件的复杂性，没有自己的功能，也不限制对substsyem的访问。通常在面向对象设计中使用。SLF4J就是一个很好的例子-它是一个用于日志系统的简单外观，允许最终用户在部署时插入所需的日志系统。

服务是一个公共接口，它提供对功能单元的访问，并始终按照规范编写。它需要支持其不同使用者所需的通信契约(基于消息的通信、格式、协议、安全性、异常等等)。其中包括流程服务-业务工作流的封装，业务逻辑服务-规则/功能的封装，数据服务-与实体的交互，数据访问管理，基础设施服务-实用功能，如监控，日志和安全。服务大多是可重用的、不相关的、松散耦合的功能单元。

它们有很多相似之处，但取决于你如何看待它。

我看到的不同之处在于，立面是从里到外设计的。您可以查看子系统并设计一个外观来提供更简单的访问。服务是在外部设计的。您可以查看您的客户/客户，定义合同并设计服务。

我对经典的GoF外观模式的理解是，它主要是为了隐藏一个糟糕的设计。作为一个经验法则，我想说的是，人们应该只需要一个外观来处理遗留代码。

我还认为，此模式之所以成为J2EE核心模式(会话外观)，主要是因为EJB规范(至少2.x版)本质上导致了糟糕的服务层设计。

因此，我对您的问题的回答是肯定的-- facade实际上是一种第一次没有正确实现的服务。如果您需要对客户端代码隐藏复杂性，这通常意味着您只设法提供了一个库，而不是服务层；因此，在这种情况下，Facade实际上成为了您的服务层。

另一方面(假设您有一个像样的域层)，如果您确实需要提供通过单个方法调用(类似宏/别名)生成复杂流的选项，这通常会更好地放在应用程序层而不是您的核心域中--请注意，我已经将分层术语切换为域驱动设计，其中没有“数据访问”或“服务”层，而是“应用程序”、“域”、“基础结构”。