Model view controller 为什么MVC如此流行？

我本来打算把这个问题延长，但我觉得越短，你就越能理解我的意思

• MVC架构模式有3个依赖项。视图取决于模型。控制器取决于视图和模型。模型是独立的

• Layers架构模式定义了N-1个依赖项，其中N是层的数量

给定三层：模型、视图和控制器，只有2个依赖项，而传统MVC只有3个依赖项。结构如下所示：

View ---> Controller ---> Model

[视图取决于控制器，控制器取决于模型]

在我看来，这种风格实现了相同的目标，并产生了更松散的耦合。为什么这种风格不更常见？它真的实现了同样的目标吗

编辑：不是ASP.NET MVC，只是模式

关于格里格斯的帖子：

• 至于模拟，层仍然允许您使用命令处理器模式来模拟按钮单击以及任何其他范围的事件
• UI更改仍然很容易，甚至可能更容易。在MVC中，控制器和视图趋向于融合在一起。层创建严格的分隔。这两个层都是黑盒，在实现中可以自由地独立变化
• 控制器对视图有0个依赖项。可以编写视图，并且通过松耦合仍然可以节省时间

---

因为您将接口与控制器分离，使更改更容易

也考虑一个场景，你需要开始一个项目，但是艺术作品不会准备好几个星期或几个月。您是等待还是编写页面所需的所有代码，然后将视图连接到控制器

至少我们这样做了，节省了几个月的时间

它还使UI更改更容易处理，因为在我们的aspx页面中没有任何代码可以做任何事情

我们的测试也更好，因为我们可以模拟任何东西，包括按钮点击等

---

如果你说的是asp.net-mvc框架，aspx文件中没有代码，也没有viewstate等。

在适当的mvc中，控制器不依赖于视图afaik。或者我没有正确理解它

模型定义了数据

视图定义了输出的外观

控制器是从模型理解语法到视图理解语法的翻译器

因此，控制器本质上是独立的。这一观点是独立的。模型是独立的

---

是吗？否？

在我看来，您最好在您的程序中尝试，您可以使用ruby on rails或codeigniter（用于php），这些伟大的框架可能有助于您理解MVC。

我将大胆地解释为什么您的方法没有流行起来

MVC模式基本上要求视图层和模型层在API上达成一致。 由于其中一个服务于另一个，并且代码中没有依赖项，因此它让控制器以一般方式运行，因此它所需要做的就是在视图层中采用特定的结构，并在模型层上调用匹配的API

您将注意到，在视图和模型之间就API达成一致并不是什么大问题，无论如何都必须这样做。您得到的是后端和前端开发之间的良好分离

在您提出的解决方案中，控制器端需要进行大量开发。控制器需要理解视图中的所有元素，并将它们映射到模型层上所需的特定调用。 由于控制器是一个连接多个视图和多个模型的单一接入点，因此很快就会失控，最终成为一个无法理解的控制器模块

---

请看一些Struts2示例，了解我的意思…

我想我理解了你的观点：

是的，通过使控制器将模型对象转换为非模型对象（如简单数组），可以使视图仅依赖于控制器

正如我们已经知道的，如果实际上不需要解耦，那么执行这种转换可能需要付出比其价值更大的努力。如果视图使用模型对象，则它具有此依赖关系。但是，通过让视图仅依赖于控制器的所需输入（可以是模型对象），可以稍微缓解这一点

---

Symfony PHP框架促进了这种在模型和视图之间切换的瘦控制器风格。您仍然可以直接调用模型层来检索视图层中的对象，但强烈建议不要使用它来解决您提出的耦合问题。在视图中，您可以调用include_component（），如果需要查询模型，它实际上会返回到控制器。

在Microsoft平台上为新的或企业web开发选择一种表示模式是一项艰巨的任务，在我看来只有三种；视图模型、模型视图演示器（MVP）或ASP.NET MVC（Model2衍生产品）

---

你可以在这里阅读全文

我想补充一些东西。首先，我的观点是，我们使用模型作为我们想要传递和显示在视图上的信息的容器。通常，进入控制器的操作方法以返回视图（“视图名称”，模型）结束。视图本身可能会根据模型更改布局：

关于这一观点：

if（model.something==true）{

%>

要展示的东西

---

我很长时间没有回到这个话题上来了，主要是因为我还在思考。我对收到的答案不满意，他们没有真正回答我的问题

最近，一位教授确实将我引向了正确的方向。本质上，他告诉我：分离模型、视图和控制器的层是MVC。在普通的MVC架构模式中，视图与模型之间的依赖关系通常不被使用，而实际上，你就结束了它