为什么MVC如此流行？
我本来打算问一个较长的问题，但我觉得我问得越短，你就越能理解我的意思。
MVC 架构模式有 3 个依赖项。视图取决于模型。控制器依赖于视图和模型。模型是独立的。
层架构模式定义了 N - 1 个依赖项，其中 N 是层数。
给定三层：模型、视图和控制器，只有 2 个依赖项，而传统 MVC 则有 3 个依赖项。结构如下所示：
View ---> Controller ---> Model
[视图取决于控制器，控制器取决于模型]
在我看来，这种风格实现了相同的目标，并且产生了更松散的耦合。为什么这种风格不更常见？它真的实现了同样的目标吗？
编辑：不是 ASP.NET MVC，只是模式。
关于 griegs 的帖子：
- 就模拟而言，图层仍然允许您使用命令处理器模式来模拟按钮单击以及任何其他范围的事件。
- UI 更改仍然非常容易，甚至可能更容易。在 MVC 中，控制器和视图倾向于结合在一起。层次创造了严格的分离。这两层都是黑匣子，在实现中可以自由地独立变化。
- 控制器对视图的依赖性为 0。 View可以写，并且通过松耦合仍然可以节省时间。
I was originally going to make this a longer question, but I feel like the shorter I make it, the better you'll understand what I mean.
The MVC architectural pattern has 3 dependencies. The View depends on the model. The Controller depends on the View and Model. The Model is independent.
The Layers architectural pattern defines N - 1 dependencies, where N is the number of Layers.
Given three Layers: Model, View, and Controller, there are only 2 dependencies, as opposed to 3 with traditional MVC. The structure looks like this:
View ---> Controller ---> Model
[View depends on Controller, Controller depends on Model]
It seems to me that this style accomplishes the same goals and produces looser coupling. Why isn't this style more common? Does it truly accomplish the same goals?
Edit: Not ASP.NET MVC, just the pattern.
With regard to griegs's post:
- As far as mocking, Layers still allows you to use the Command Processor pattern to simulate button clicks, as well as any other range of events.
- UI changes are still very easy, perhaps even easier. In MVC, the Controller and View tend to mesh together. Layers creates a strict separation. Both Layers are black boxes, free to vary independently in implementation.
- The Controller has 0 dependencies on the View. The View can be written, and time can still be saved with loose coupling.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
因为您将接口与控制器分离，从而使更改变得更加容易。
还要考虑这样的场景：您需要开始一个项目，但艺术品需要数周或数月才能准备好。您是等待还是编写页面所需的所有代码，然后将视图连接到控制器。
至少我们就是这样做的，并且节省了几个月的时间。
它还使 UI 更改更容易处理，因为我们的 aspx 页面中没有任何代码执行任何操作。
我们的测试也更好，因为我们可以模拟任何东西，包括按钮点击等。
如果你谈论的是 asp.net-mvc 框架，那么 aspx 文件中没有代码，也没有视图状态等。
Because you decouple the interface from the controller making changes easier.
Also consider the scenario where you need to get started on a project but the artwork won't be ready for weeks or months. Do you wait or do you write all the code required for the pages and simply then wire up the view to the controller.
At least that's what we did and we saved months.
Also it made UI changes easier to cope with because there wasn't any code in our aspx pages that did anything.
Our tests were also better as we could mock up anything including button clicks etc.
And if you're talking about the asp.net-mvc framework, there is no code in the aspx files and no viewstate etc.
在正确的 MVC 中，控制器不依赖于视图。或者也许我没有正确理解它。
模型定义数据。
视图定义了输出的样子。
控制器是从模型理解的语法到视图理解的语法的翻译器。
所以本质上控制器是独立的。视图是独立的。并且模型是独立的。
是的？不？
In proper MVC the controller doesn't depend on the view afaik. Or maybe I'm not understanding it correctly.
The model defines the data.
The view defines what the output looks like.
And the controller is a translator from a model-understood grammar to view-understood grammar.
So essentially the controller is independent. The view is independent. And the model is independent.
Yes? No?
我会大胆地尝试解释为什么你的方法没有流行起来。
MVC 模式基本上要求视图层和模型层就 API 达成一致。
由于一个为另一个服务，并且代码内部没有依赖关系，所以控制器的行为是通用的，所以它需要做的就是在视图层中采用某种结构并在模型层上调用匹配的 API。
您会注意到，在视图和模型之间就 API 达成一致并不是什么大事，无论如何都必须发生。您得到的是后端前端开发之间的良好分离。
在您提出的解决方案中，控制器端需要进行大量开发。控制器需要理解视图中的所有元素并将它们映射到模型层所需的特定调用。
由于控制器是连接多个视图和多个模型的单一访问点，因此很快就会失控并最终成为难以理解的控制器模块。
看看一些 Struts2 的例子就明白我的意思了……
I'll be bold, and try to explain why your method didn't catch on.
The MVC pattern basically requires the view and model layers to agree on an API.
Since one serves the other and there are no dependencies inside the code it leaves the controller to behave generically, all it needs to do is take a certain structure in the view layer and call the matching API on the model layer.
You'll note that agreeing on an API between the view and model isn't really such a big deal it has to happen anyway. And what you get is good separation between back-end front-end development.
In your proposed solution a lot of development is required on the controller side. The controller will be required to understand all the elements in the view and to map them to the specific calls required on the model layer.
Since the controller is a single access point connecting many views to many models this can quickly get out of hand and end up being an incomprehensible controller module.
Look at some Struts2 examples to see what I mean...
我想我理解你的观点：
是的，你可以通过控制器将模型对象转换为非模型对象（例如简单数组）（以 PHP 为例），从而使视图仅依赖于控制器。
正如我们所知，如果实际上不需要解耦，则执行此转换可能会付出更多的努力而不值得。如果视图使用模型对象，那么它就具有这种依赖性。但是，通过让视图仅依赖于控制器来获取所需的输入（可以是模型对象），可以稍微缓解这一问题。
Symfony PHP 框架提倡这种在模型和视图之间进行瘦控制器调整的风格。您仍然可以直接调用模型层来检索视图层中的对象，但强烈建议您不要这样做，以解决您提出的耦合问题。在视图中，您可以调用 include_component() ，如果您需要查询模型，它实际上会返回到控制器。
I think I'm understanding your point:
Yes you can make the View only depend on the Controller only by making the Controller transform (using PHP as an example) the Model objects to non-Model objects like simple arrays.
As we already know, performing this transformation can be more effort than it's worth if the decoupling isn't actually needed. If the View uses the Model objects then it has this dependency. However, this can be relieved a bit by having the View depend solely on the Controller for its required input, which can be Model objects.
The Symfony PHP framework promotes this style of skinny controller shuffling between Model and View. You can still directly call upon the Model layer to retrieve objects within the View layer but it's strongly urged against for the coupling issues you bring up. Within the View you can call include_component() which actually goes back up to the Controller if you need to query the Model.
我已经很久没有回过头来了，主要是因为我还在思考。我对收到的答案不满意，他们没有真正回答我的问题。
最近，一位教授确实引导我走向了正确的方向。本质上，他告诉我：分离模型、视图和控制器的层是 MVC。在普通的 MVC 架构模式中，通常不使用视图与模型之间的依赖关系，并且实际上最终会得到层。想法是一样的，只是命名不好。
I haven't gotten back to this in a long time, mostly because I was still thinking. I was unsatisfied with the answers I received, they didn't really answer my question.
A professor, recently, did steer me in the right direction. Essentially, he told me this: Layers which separate Model, View, and Controller is MVC. In the vanilla MVC architectural pattern, the dependency between the View to the Model is often not used, and you effectively end up with Layers. The idea is the same, the naming is just poor.
在 Microsoft 平台上为新的或企业 Web 开发选择表示模式是一项艰巨的任务，在我看来只有三种；视图模型、模型-视图-呈现器 (MVP) 或 ASP.NET MVC（Model2 衍生品）。
您可以在此处阅读完整文章 ASP.NET MVC 模式
Choosing a presentation pattern for a new or enterprise web development on the Microsoft platform is a daunting task, in my opinion there are only three; View Model, Model-View-Presenter (MVP) or ASP.NET MVC (a Model2 derivative).
You can read the full article here ASP.NET MVC Patterns
我想补充一些东西。首先，我的观点是，我们使用模型作为我们想要传递并在视图上显示的信息的容器。通常控制器中的操作方法以 return view("viewName",model) 结束。视图本身可能会根据模型更改其布局：
在视图上：
if(model.something==true) {
%>;
somethign to show
<%
}
此时模型的定义很难找到。
我可以说（特别是在企业环境中）有两个“模型”，
一个是域模型/实体模型，或者你想如何称呼它，它包装来自较低层（数据库等）的数据和视图模型包含我们想要显示的信息以及我们需要隐藏/显示界面部分的任何其他信息
控制器编排视图并且独立于视图，但有点依赖于模型：
进入控制器
pulic actionResult Index(){
。 ...
if(model.BoolProperty==true){
return ("firstView);
}
else
{
return ("secondView");
}
}
我希望这是有道理的
I'd like to add some more things. First of all for my point of view is we use the model as container for the information we want to pass and show on the view. Usually the action method into the controller ends with return view("viewName",model).The view itself probabily will change its layour against the model :
on the view :
if(model.something==true) {
%>
somethign to show
<%
}
At this poinf the definition of model is hard to find.
I can say (especially on enterprise conext) the are two "model"
one is the domain model/entity model or how you want to call it that wraps the data coming from the lower layers (database,etc) and the view-model who contain the information we wants to show plus any other information we need to hide/show portion of interface
The controller orchestrate the the views and is indipendent from the view but a bit dipendent from the model:
into the controller
pulic actionResult Index(){
....
if(model.BoolProperty==true){
return ("firstView);
}
else
{
return ("secondView");
}
}
I hope it makes sense
在我看来，你最好在你的程序中尝试一下，你可以使用ruby on Rails，或者codeigniter（对于php），这些很棒的框架可能有助于你理解MVC。
In my opinion ,you'd better try it in your programme , you can use ruby on rails ,or codeigniter( for php ),these great framework may be helpful to your understanding the MVC.