服务和DAO与MVC

时间:2017-08-03 17:16:06

标签: design-patterns service dao

我对设计模式非常陌生,我不断遇到像Service图层,DAO图层和图片等文字。编程中的Model-View-Controllers

由于 StackOverflow 是非常棒的平台,在解释概念和/或逻辑方面拥有许多非常有才华的受众。

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

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

2 个答案:

答案 0 :(得分:5)

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

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

服务将使用Model对象来完成View请求,并使用数据访问层将结果保存到数据库。

这是架构的样子:

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

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

如今,您将听到很多关于微服务的信息,特别是REST。你可能想知道它们在哪里适合。

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

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

答案 1 :(得分:4)

  

服务和DAO与MVC

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

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

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

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