服务和DAO与MVC

Question

我对Design Patterns确实很陌生，并且经常遇到诸如ServiceLayers，DAOLayers和Model-View-Controllersin Programming之类的词。

由于StackOverflow是一个非常出色的平台，在解释概念和/或逻辑时有许多非常有才华的观众。

我期望得到一个优雅的答案，这可以向我解释所有这些之间的区别。我们什么时候使用它们？什么时候我们比MVC模式更喜欢Service / DAO体系结构？我们在Service / DAO体系结构中有控制器吗？我们可以集成Service / DAO和Model / View / Controller的可能组合是什么？

---

该职位也将对所有其他有相同疑问的人有所帮助。好的帖子应该始终得到支持。请求主持人不要将其作为其他问题的副本来关闭，因为SO上的任何问题都无法解决我的查询。

Answer 1

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

服务/ DAO将这些层扩展到服务器端。您可以想象一个Web控制器将拥有多个Service实例，这些实例将更新模型以实​​现View请求。

服务将使用Model对象来满足View请求，并使用数据访问层将结果持久保存到数据库中。

架构如下所示：

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

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

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

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

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

Answer 2

服务和DAO与MVC

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

服务层是通用术语，主要充当应用程序域的入口点，通常包括业务逻辑。对于Web应用程序，您可以将业务逻辑层视为服务层，对于移动客户端，您可以公开Web API并将其视为服务层。简而言之，不管使用GUI / Client，您都应该能够按原样重用业务逻辑。

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