为什么MVC如此受欢迎？

我原本打算让这个问题更长一些，但我觉得我做得越短越好，你会明白我的意思。为什么MVC如此受欢迎？

MVC架构模式有3个依赖关系。该视图取决于模型。控制器取决于视图和模型。该模型是独立的。
各层架构模式定义N - 1间的依赖关系，其中，N是层的数量。

给定三层：模型，视图和控制器，只有2个依赖关系，而传统的MVC只有3个。该结构是这样的：

View ---> Controller ---> Model

[查看取决于控制器，控制器取决于型号]

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

编辑：没有ASP.NET MVC，只是格局。

关于griegs的帖子：

至于嘲讽，图层仍然允许您使用命令处理器模式来模拟按钮点击，以及其他一系列活动。
用户界面的变化仍然很容易，甚至可能更容易。在MVC中，控制器和视图倾向于一起啮合。图层会创建严格的分隔。两个图层都是黑色框，可以在实现中自由变化。
控制器对视图有0依赖性。视图可以被写入，并且时间仍然可以通过松耦合来保存。

来源

2010-09-02 Mike

我还没有得到回到这个在很长一段时间，主要是因为我还在想。我不满意我收到的答案，他们没有真正回答我的问题。

最近，一位教授指导我走向正确的方向。实质上，他告诉我：分开模型，视图和控制器的层是 MVC。在vanilla MVC体系结构模式中，View和Model之间的依赖关系通常不被使用，而且最终会有效地使用Layers。这个想法是一样的，命名只是很差。

来源

2010-11-03 12:16:07 Mike

因为你从更改更容易控制分离的接口。

还要考虑场景，你需要获得一个项目开始，但作品将不准备数周或数月。您是等待还是编写页面所需的所有代码，然后将视图连接至控制器。

至少，这就是我们所做的，我们保存几个月。

而且它使用户界面的变化更容易应对，因为没有在做了什么我们的aspx页面的任何代码。

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

如果你正在谈论的asp.net MVC架构，有在ASPX文件并没有视图状态无码等等。

来源

2010-09-02 01:14:04 griegs

你假设他指的是ASP.NET MVC，而不是MVC模式，这是他问到的。 – 2010-09-02 01:15:36

+10

不，我不是。只有在我最后一次转变时，我才会这样做，我甚至会说“如果你正在谈论......” – griegs 2010-09-02 01:19:35

视图和控制器，并且固有地与MVC耦合。由于两者都被模拟为黑匣子，每个都可以被嘲弄和/或修改。我不觉得你指出了区别，非常相似。 – Mike 2010-09-02 01:20:27

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

该模型定义了数据。

该视图定义了输出的样子。

而控制器是从模型理解的语法转换为视图理解的语法。

所以基本上控制器是独立的。该视图是独立的。模型是独立的。

是吗？没有？

来源

2010-09-02 01:14:46

这是我的印象： http://prajwal-tuladhar.net.np/wp-content/uploads/2008/10/mvc-architecture.png – Mike 2010-09-02 01:18:02

每一个（或多或少）都是独立的，但你的角色是控制器错误。控制器基本上接受用户输入，并相应地修改模型或视图（尽管有些实现绕过控制器仅执行修改视图的操作）。 – 2010-09-02 01:39:27

-1

在我看来，你最好在你的程序中尝试一下，你可以在rails或codeigniter（用于php）上使用ruby，这些很棒的框架可能会有助于你理解MVC。

来源

2010-09-02 01:35:53 keepyouliking

CakePHP也是很好的PHP MVC框架。有了Perl，你可以尝试Catalyst。 .NET和Java，好吧，我猜每个人都已经知道了大名:) – 2010-09-02 01:56:35

我会大胆的，并试图解释为什么你的方法没有得到满足。

MVC模式基本上要求视图和模型层在API上达成一致。由于一个服务于另一个，并且代码内部没有依赖项，所以它只需要在视图层采用特定的结构，并在模型层上调用匹配的API。

你会注意到，在视图和模型之间商定一个API并不是真的这么重要，它必须发生。而你得到的是后端前端开发之间的良好分离。

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

看一些Struts2的例子来看看我的意思...

来源

2010-09-02 01:41:18 Asaf

控制器层需要绝对不依赖于视图层。事实上，这种模式限制了它。此外，MVC声明每个视图有一个控制器，多个视图和一个模型。所以这也被照顾了。 – Mike 2010-09-02 01:45:24

因此，如果我在网页上提交表单（视图）如何应用适当的业务逻辑（模型）？如果您的视图和型号是真正独立的，则控制器必须具有以下定义：（input1 - > call methods 1,2,3）（input2 - > call methods 2,3,5） ... 我相信这是模式的大多数实现都试图避免 – Asaf 2010-09-02 01:51:00

如果方法1,2,3是模型方法，具有讽刺意味的是，我试图实现这一点。这很有道理。闻起来甚至很容易清理Command模式。 – Mike 2010-09-02 01:55:53

我想我理解你的观点：

是的，你可以查看仅只有将控制器取决于控制器将Model对象转换（使用PHP作为示例）到非模型对象（如简单数组）。我们已经知道，如果实际上不需要解耦，那么执行这种转换可能比它的价值更努力。如果视图使用模型对象，则它具有此依赖性。但是，通过使View仅依赖Controller的所需输入（可以是Model对象），可以缓解这一点。

Symfony PHP框架在Model和View之间推广了这种Skinny控制器混洗的风格。您仍然可以直接调用Model层以检索View层中的对象，但强烈建议您避免出现耦合问题。在View中，如果需要查询模型，您可以调用include_component（），实际上它返回到Controller。

来源

2010-09-02 03:18:23

是的，你已经知道了，@Rob Olmos。所以有时会使用它。我只是感到惊讶，它没有被更多地使用，特别是因为有一段时间没有人真正理解我在说什么。 – Mike 2010-09-02 11:44:55

即使在我的组织中，我们仍然在争论是否强制Controller仅将非模型变量传递给视图..尚未做出决定，但我们正在试验它的可行性...... – 2010-09-03 03:12:40

为微软平台上的新型或企业Web开发选择演示模式是一项艰巨的任务，我认为只有三种;查看模型，模型 - 视图 - 演示者（MVP）或ASP.NET MVC（Model2派生）。

你可以在这里阅读完整的文章ASP.NET MVC Patterns

来源

2010-09-02 08:26:02 MetalLemon

我想添加一些更多的东西。首先，为了我的观点，我们使用该模型作为容器，用于我们想要传递并显示在视图上的信息。

在视图：一般操作方法到控制器与返回视图（“的viewName”，型号）。该图本身probabily将改变其layour靠在模型结束

如果（model.something ==真）{

％>

somethign显示

<％

}

在这一点上，模型的定义很难找到。

我可以说（特别是在企业conext）的两个“模式”

一个是域模型/实体模型或你想怎么称呼它包裹从下层传来的数据（数据库，等等）以及包含我们想要显示的信息的视图模型加上我们需要隐藏/显示接口的一部分的任何其他信息

控制器编排视图并且与视图独立，但与视图独立型号：

进控制器

pulic的ActionResult指数（）{

....

如果（model.BoolProperty ==真）{

回报（“的firstView）;

}

别的

{

返回（ “secondView”）;

}

我希望这是有道理的

来源

2010-11-03 12:06:47

为什么MVC如此受欢迎？

回答

相关问题