服务和外观的角色是否相似？

Question

我读的越多,我就越困惑.

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

我的理解是Facade不是一个超级智能对象,它只是一种暴露简单接口/ api来执行复杂操作的方式(例如:执行10 $付款,这是一个复杂的操作,涉及一些操作,但这样的复杂性可以通过一个外观来处理,它只会按特定的顺序调用相应的对象......等等...)

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

那么问题是,外观和服务之间有什么区别？在一天结束时,外观可以完美地访问几个DAO,以便通过提供简单的界面来执行复杂的操作,并且服务似乎类似于某些东西.

交易也是如此,我知道服务是开始交易的地方,但我同样觉得它们也可以放在外墙上,毕竟外立面也可以调用几个DAO.

那么哪个堆栈会更有意义

controller-facade-dao controller-service-dao

或者可能

controller-facadade-dao有时候是controller-facade-service-dao ??

Answer 1

一个服务是书面形式向外部系统的接口,如LDAP身份商店,支付网关或应用管理界面的一种方式.这是一种概念性的方式,将外部系统看作是有用服务的提供者,可能具有内部行为而不是被动操作.

阿立面是结束了任何东西(包括服务),以很好地呈现它到另一部件的方法.在以下情况下经常使用外墙:

• 库或组件很复杂,您的应用程序只需要它的一部分.Facade为应用程序提供了简化的API
• 您正在使用多个库或组件,需要统一它们,向应用程序提供合并的API
• 您正在使用的库具有复杂的设置或一组依赖项,并且Facade在应用程序的上下文中包含所有这些内容.

令人困惑的是,您可以(并且通常会)在一个或多个服务上创建外观.服务是组件实际访问资源的方式,而Facade是简化组件的位(例如选项配置,连接等).

如果您编写自己的DAO,您可能会根据需要创建服务,因此编写外观表明您做错了.如果DAO是由第三方构建的,并且比您的需求更复杂,那么您可以使用该服务.

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

我会说DAO是一个独立的设计模式 - 请参阅维基百科.

如果我们将DAO与服务进行对比,我们有:

• API级别:
  • DAO:细粒度访问属性
  • 服务:粗粒度访问服务
• 实施在哪里:
  • DAO:主要在客户端上,但在数据库中存储数据(没有行为)
  • 服务:主要在服务器上
• 如何调用接口
  • DAO:客户端直接绑定到同一名称空间和JVM中的对象
  • 服务:客户端只是网络,跨vm或跨命名空间操作的存根

...外观可以完美地访问几个DAO,以便通过提供简单的界面来执行复杂的操作,并且服务似乎是类似的.

一个门面可以包装DAO层,但我并没有真正看到这种情况发生在一个有用的方式.很可能你需要一个API来访问对象的各个属性,遍历对象图和类似的东西,这正是DAO提供的.

交易也是如此,我知道服务是启动交易的地方......

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

......但是我同样觉得它们也可以放在外墙上,毕竟外立面也可以叫几个DAO.

在许多方面,事务管理器服务是一个更复杂的后端实现的外观,协调Web上的事务,应用程序,数据库和其他事务感知组件.但是,这已经被事务服务实现抽象掉了.就我们而言,用户而言,只有公共接口.

事实上,这是这些设计模式的概念点 - 为用户提供适量的API,从而抽象出组件界面铁墙背后的实现的复杂性.

那么哪个堆栈会更有意义

controller-facade-dao controller-service-dao

或者可能

controller-facadade-dao有时候是controller-facade-service-dao ??

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

因此,正确答案是:

• 控制器 - dao

Answer 2

从字面上看,Facade顾名思义就是建筑物的正面.走过马路的人只能看到立面,他们对里面的东西,布线,管道和其他复杂性一无所知.面部隐藏了建筑的所有复杂性,并显示出更简单的友好面孔.

在软件术语中,Facade通过提供更简单的接口来隐藏其背后的软件组件的复杂性,不具有其自身的功能并且不限制对substsyem的访问.常用于面向对象设计.很好的例子是SLF4J - 它是一个api,它是日志系统的简单外观,允许最终用户在部署时插入所需的日志记录系统.

服务是一个公共接口,提供对功能单元的访问,并始终写入规范.它需要支持不同消费者需要的通信合同(基于消息的通信,格式,协议,安全性,异常等).有流程服务 - 业务工作流的封装,业务逻辑服务 - 规则/功能的封装,数据服务 - 与实体的交互,数据访问管理,基础设施服务 - 监控,日志和安全等实用功能.服务主要是可重用,无关联,松散耦合的功能单元.

它们很相似,但取决于你如何看待它.

我看到的不同之处在于,Facades的内部设计.您可以查看子系统并设计外观以提供更简单的访问.服务是在外面设计的.您可以查看您的客户/客户定义合同并设计服务.

Answer 3

我对经典 GoF Facade 模式的理解是，它主要是为了隐藏糟糕的设计。根据经验，我想说，遗留代码应该只需要一个外观。

我还认为该模式成为 J2EE 核心模式（Session Facade）主要是因为 EJB 规范（至少达到 2.x）本质上导致了糟糕的服务层设计。

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

另一方面（假设您有一个不错的域层），如果您确实需要提供通过单个方法调用（类似于宏/别名的东西）生成复杂流的选项，那么通常最好将其放置在应用程序层中，并且不在你的核心领域——请注意，我已将分层术语切换为领域驱动设计，其中没有“数据访问”或“服务”层，而是“应用程序”、“域”、“基础设施”。