java - 服务和外观的角色是否相似?

标签 java spring model-view-controller design-patterns facade

我读得越多,我就越困惑。

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

我的理解是,Facade 并不是一个 super 智能的对象,它只是暴露一个简单的接口(interface)/api 来执行复杂操作的一种方式(例如:执行 10 美元的支付,它是一个复杂的操作,涉及许多操作,但这种复杂性可以由外观处理,它只会以特定顺序调用相应的对象......等等......)

现在,服务是一种调用多个 DAO 以获取复杂数据结构的方法(我不太确定,但目前为止我所理解的)。

那么问题是,门面和服务有什么区别?归根结底,Facade 可以通过提供一个简单的接口(interface)完美地访问多个 DAO 以执行复杂的操作,而服务似乎是类似的东西。

事务也是如此,我知道服务是开始事务的地方,但我同样觉得它们也可以放在门面上,毕竟门面也可能调用多个 DAO。

那么哪个堆栈更有意义

Controller 外观道 Controller 服务道

或许

controller-facade-dao 有时还有 controller-facade-service-dao ??

最佳答案

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

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

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

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

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

Now, a service is a way to perform calls to several DAOs in order to get complex data structures (I am not too sure of this, but is is what I understand so far).

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

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

  • API 级别:
    • DAO:对属性的细粒度访问
    • 服务:对服务的粗粒度访问
  • 实现所在:
    • DAO:主要在客户端,但在数据库中存储数据(无行为)
    • 服务:主要在服务器上
  • 如何调用接口(interface)
    • DAO:客户端直接绑定(bind)在同一个命名空间和JVM中的对象
    • 服务:客户端只是网络、跨虚拟机或跨命名空间操作的 stub

... the facade can perfectly access several DAOs in order to perform a complex operation by providing a simple interface, and a service seems to to something similar.

外观可以包裹 DAO 层,但我真的不认为这会以有用的方式发生。您很可能需要一个 API 来访问对象的各个属性、遍历对象图等,而这正是 DAO 提供的。

Same happens with transactions, I understand that a service is the place to start transactions ...

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

... but I equally feel that they could also be placed on facades, after all, a facade may call several DAOs too.

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

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

So which stack would make more sense

controller-facade-dao controller-service-dao

or maybe

controller-facadade-dao AND sometimes controller-facade-service-dao ??

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

因此正确答案是:

  • Controller - 道

关于java - 服务和外观的角色是否相似?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/15038324/

相关文章:

java - spring security Rest API错误-403禁止

java - 根据配置文件在 Spring 中加载属性文件

winforms - 使用 Entity Framework 作为 ORM 的 Winform 应用程序的 MVC 或 MVP 架构

java - Spring MVC注解@ModelAttribute

java - 如何将我的 rest API 映射到根上下文来提供来自 CXF/JAX-RS 的静态内容?

java - 简单java项目的日志记录

java - 但为什么 swing 不绘制我的组件?

java - 'sort' 属性有什么作用?

java - 使用依赖注入(inject)连接多个配置类

oop - MVC/观察者和不可变数据结构