服务和 DAO 与 MVC

Question

我确实是设计模式的新手，我经常在编程中遇到Service Layers、DAO Layers 和Model-View-Controllers 这样的词。

StackOverflow 是一个非常棒的平台，在解释概念和/或逻辑方面拥有许多非常有才华的观众。

我期待一个优雅的答案来解释所有这些之间的区别。我们什么时候使用它们？什么时候我们更喜欢服务/DAO 架构而不是 MVC 模式？我们在 Service/DAO 架构中有控制器吗？我们可以在哪些组合中集成 Service/DAO 和 Model/View/Controller。

---

这篇文章也应该对所有有同样疑问的人有所帮助。好的帖子应该永远支持。请版主不要将此作为其他问题的副本关闭，因为关于 SO 的任何问题都无法解决我的查询。

Answer 1

MVC 回到 Smalltalk。 Model-View-Controller 通常表示“用户界面”。 Controller 是一个服务器端组件（用于 Web 应用程序），它接受来自 View 客户端的请求，适当地更新模型，并将结果发送回任何和所有需要它的 View 客户端。

Service/DAO 将这些层扩展到服务器端。您可以想象一个 Web Controller 将拥有多个更新模型以满足视图请求的服务实例。

服务将使用模型对象来满足视图请求并使用数据访问层将结果保存到数据库中。

架构如下：

View ---> Controller ---> Service ---> Data Access Layer

模型以一种或另一种形式存在于所有层中。

这些天你会听到很多关于微服务的信息，尤其是 REST。您可能想知道它们在哪里适合。

这是实现服务层的一种方式。

我认为 View 和 Controller 紧密结合在一起。它们将用于客户端和后端之间的通信。用户界面变化很大 - 例如。台式机/平板电脑、浏览器、移动设备等 - 但它们都可以使用相同的后端服务来完成任务。

Answer 2

服务和 DAO 与 MVC

您不应将它们直接相互比较。服务和 DAO 在任何 n 层应用程序中形成层。 MVC 应用程序可以包含服务和 DAO。

服务层是一个通用术语，基本上充当应用程序域的入口点，通常包括业务逻辑。对于 Web 应用程序，您可以将业务逻辑层视为服务层，或者对于移动客户端，您可以公开 Web API 并将其视为服务层。简而言之，无论 GUI/客户端如何，您都应该能够按原样重用业务逻辑。

DAO只是抽象出数据存储机制的对象。

MVC 是一种设计模式，其中 V 和 C“严格”构成表示层，而 M 可以包含所有超出表示 (GUI) 的内容。 MVC 中的模型部分长期以来一直是一个基于意见的话题。但这是我构建典型 MVC 应用程序的方式。

Presentation Layer
  -> Views
  -> ViewModels  
  -> Controllers 

Service Layer
  -> Includes business logic
  -> Uses data access interfaces

Data Access Layer (DAOs)
  -> Contracts (interfaces) for persistent storage
  -> Interface implementations

Entities
  -> POCO/ POJO that represent data