我已经搜索过那个答案,但看起来每个人对此都有不同的理解:(与 3 层/3 层相比)
"
模型 - 业务逻辑
视图 - 表示逻辑
控制器 - 改变模型和视图的状态(基于使用输入)
"
其他人写道:
" 视图 = 前端(表示逻辑)
模型 = 后端(数据访问层?)
控制器 = 前端和后端之间的粘合(中间层?业务逻辑)“
如果我理解正确的话:
模型——是业务逻辑层吗?
视图 - 是表示层\层吗?
控制器 - ?
我已经搜索过那个答案,但看起来每个人对此都有不同的理解:(与 3 层/3 层相比)
"
模型 - 业务逻辑
视图 - 表示逻辑
控制器 - 改变模型和视图的状态(基于使用输入)
"
其他人写道:
" 视图 = 前端(表示逻辑)
模型 = 后端(数据访问层?)
控制器 = 前端和后端之间的粘合(中间层?业务逻辑)“
如果我理解正确的话:
模型——是业务逻辑层吗?
视图 - 是表示层\层吗?
控制器 - ?
答案并不像看起来那么简单,因为 MVC 在不同的上下文中意味着不同的东西。
经典 MVC(Smalltalk、C++、Java)
Web 应用程序中的 MVC
ASP.Net MVC 中的 MVC
有关 MVC (3) 管道的完整视图,请参阅此文档。
查看= 仅输出和输出逻辑
模型= 数据 任何相关的数据都应该来自模型
Controller = 连接 View 和 Model 并且可以做应用程序逻辑的东西
业务逻辑 = 进一步的业务逻辑,通常打包成类。
用户说给我 acme.com/home 控制器说,我知道如何处理 /home 哦,是的,我有一个 homeController homeController 说嘿,我会从模型中获取一些东西,或者从类中调用一些业务逻辑然后放它在某个视图可以访问它的地方(viewbag) 这个位有时被称为 applicationLogic homeController 然后说好的 我已经完成了所有这些现在我很可能会给你一个视图 View 在那里打招呼,并且可以从 viewbag 输出任何东西控制器刚刚为我们准备
请记住,控制器控制着一切,视图与任何东西都没有对话,这是一个简单的正确图表,许多图表是不同的,您可以说它可以解释,但视图与模型对话的图表不是 MVC imo。
MVC
我不确定另一种意见是否会有所帮助,因为您听起来好像已经很困惑。
但我认为 MVC 实际上是一个旧概念,可以追溯到 Smalltalk 时代,需要一些修改。
更现代的方法是考虑层次:
View --> Controller --> Service --> Persistence
该View
层是向最终用户显示的 HTML 或移动视图页面。
Controllers
紧密耦合到View
. 如果您更改View
,很可能您也必须更改Controller
。它负责侦听来自View
、验证和绑定输入参数的请求,将它们传递给Services
用例,确定适当的 next View
,并将响应序列化回最终用户。
映射到用Service
例并完成工作单元。它负责交易。它独立于View
; 即使Views
发生变化,它也可能会继续存在。它是面向服务架构的基础。它应该从一个接口开始,它允许您使用您喜欢的任何技术部署它:EJB、SOAP 或 REST Web 服务、XML-RPC 等。
Persistence
对其他人隐藏数据库。它处理所有 CRUD 操作。
Model
在所有层之间浮动。这些是描述您正在解决的问题的对象(例如,银行业务的帐户、客户等)。
“图表”中的箭头是有意义的。它模仿了对象在这种安排中的包依赖关系。 Persistence
不知道Service
;Service
不知道Controller
。
这些应该是基于接口的,因此您可以在不影响客户端的情况下更改实现。
我倾向于这样看待它:
模型:蓝图,主要是我的对象类
视图:用户将如何看到它,我如何呈现它
管制员:任何需要进行的计算、更改……。它充当视图和模型之间的一个步骤。它操纵数据。
它们是分层依赖的:
模型 - 原始数据模型,带有控制器的对象提取
控制器 - 控制来自模型的数据为视图转换的方式
View - 表示层,从 Controller 中提取数据使其非常漂亮。
对于 XML,这是:
XML -> XSLT -> HTML