我正在考虑在我的新项目中使用 MVC 模式，我可以清楚地看到能够将数据层（模型）更靠近表示层（视图）的主要优势，这将允许稍微增加在应用速度上。但是除了性能方面，MVC 与视图-逻辑-数据分层类型模式相比还有其他优势吗？
编辑： 对于那些有兴趣的人，我刚刚上传了一个我创建的示例 PHP 代码，用于测试 MVC 的使用。我故意省略了所有安全检查以使代码更易于阅读。请不要过多批评它，因为我知道它可能会更加精致和先进，但是 - 它有效！欢迎提出问题和建议：这里是链接： http: //www.sourcecodester.com/sites/default/files/download/techexpert/test_mvc.zip
被引用为 MVC 优势的关注点分离实际上也是 3-layer/3-tier 系统的进步。在那里，业务逻辑也是独立的，可以从不同的表示层使用。
一个主要区别是，在经典 MVC 中，模型可以有对视图的引用。这意味着当数据更新时，模型可以将此数据推送回可能的多个视图。最好的例子是一个桌面应用程序，其中数据以多种方式可视化。这可以像表格和图表一样简单。表中的更改（这是一个视图中的更改）首先通过控制器推送到模型，然后将其推送回图形（另一个视图）。然后图表会自行更新。
由于桌面开发正在走下坡路，许多程序员只接触到一些 Web 变体中的 MVC，例如通过 Java EE 中的 JSF。
在这些情况下，模型几乎从不引用视图。这是因为 Web 主要是基于请求/响应的，并且在服务请求后，服务器无法发送附加信息。即从模型推送到客户端的更新将毫无意义。使用反向 ajax/comet，这种情况正在发生变化，但是许多基于 Web 的 MVC 框架仍然没有充分利用这一点。
因此，在基于 Web 的 MVC 的情况下，M、V 和 C 之间的典型“三角形”较少，并且 MVC 变体实际上比“真正的”MVC 更接近 n 层模型。
另请注意，一些 Web MVC 框架在 M、V 和 C 之间有一个中间管道部分，称为支持 bean (Java/JSF) 或代码背后 (ASP.NET)。在 JSF 中，控制器由框架提供，视图通常不直接绑定到模型，而是使用此支持 bean 作为中介。支持 bean 非常苗条，基本上只是以一种方式从模型中预取数据，并将模型特定消息（例如异常）转换为视图特定消息（例如一些人类可读的文本）。
旁
@bakoyaro 和 @arjan 已经提到过
我认为 MVC 与“约定优于配置”模式相结合时优于 3 层。（即“ruby on rails”或微软的“MVC for asp.net”）。
在我看来，这种组合会导致更好、更容易的代码维护。
首先，它使学习 mvc 框架更加困难，因为您必须学习约定（la 控制器进入控制器文件夹并且必须命名为 xxxxxcontroller）
但是在你学会了这些约定之后，维护你自己的和外国的代码就更容易了。
忘记通过迁移到 MVC 来提高应用程序速度。我发现最大的好处是易于代码重用。一旦迁移到 MVC，就不再依赖于数据的呈现或实际数据的存储。
例如，您可以编写一个 servlet，将 .jsp 页面作为您的表示层，然后在第二天编写一个 Web 服务作为您现有模型和控制器的另一个表示层。如果您想要或需要切换 DBMS，同样明智。由于访问模型与其他所有内容完全分开，因此您只需要重写数据访问对象即可以控制器可以处理的方式返回数据。
通过将关注点分成 3 个不同的部分，您还可以促进真正的单元测试。您的表示层可以在没有模型或控制器的情况下进行测试，反之亦然。
另一方面，我经常觉得 MVC 缩写是不准确的。每当我看到它时，我都会认为它是View->Controller->Model。表示层中永远不会有 DAO 代码，模型中也永远不会有表示逻辑。控制器被迫充当中间人。
在 3 层将表示与业务和数据访问分开的地方，MVC 是一种表示层模式，它进一步将模型（数据）与视图（屏幕）和控制器（输入）分开。
没有选择 MVC 而不是 3-tier/3-layered。使用它们。