我对设计模式非常陌生,我不断遇到像Service
图层,DAO
图层和图片等文字。编程中的Model-View-Controllers
。
由于 StackOverflow 是非常棒的平台,在解释概念和/或逻辑方面拥有许多非常有才华的受众。
我期待一个优雅的答案,解释了我所有这些之间的区别。我们什么时候使用它们?我们什么时候更喜欢服务/ DAO架构而不是MVC模式?我们在Service / DAO架构中有控制器吗?我们可以在哪些组合中集成Service / DAO和Model / View / Controller。
这篇文章对所有有同样疑问的人也有帮助。应始终支持好帖子。请求版主不要将此作为其他问题的副本关闭,因为SO上的任何问题都无法解析我的查询。
答案 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