我正在考虑在我的新项目中使用MVC模式，我可以清楚地看到能够将数据层（模型）更接近表示层（视图）的主要优势，这将允许应用程序速度略有提高。但除了性能观点之外，MVC还是在视图 - 逻辑 - 数据分层类型模式上还有其他优势吗？
修改 对于那些感兴趣的人，我刚刚上传了我创建的示例PHP代码，以测试MVC的使用。我故意省略所有安全检查以使代码更容易阅读。请不要过多批评它，因为我知道它可以更加精致和先进，但不过 - 它有效！我将欢迎提出问题和建议：以下是链接：http://www.sourcecodester.com/sites/default/files/download/techexpert/test_mvc.zip
答案 0 :(得分：42)
引用作为MVC优势的关注点的分离实际上也是3层/ 3层系统的进步。在那里，业务逻辑也是独立的，可以从不同的表示层使用。
主要区别在于，在经典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非常小，基本上只是从模型中预取数据，并将模型特定消息（例如异常）转换为视图特定消息（例如一些人类可读文本）。
答案 1 :(得分：6)
旁边
已经被@bakoyaro和@arjan
提及我认为当与“约定优于配置”模式结合使用时，MVC优于3层。 （即“ruby on rails”或微软“MVC for asp.net”）。
在我看来，这种组合导致更好更容易的代码维护。
首先，它使学习mvc-framework更加困难，因为你必须学习约定（la控制器进入controllers文件夹，必须命名为xxxxxcontroller）
但是在学习了这些约定之后，维护自己的代码和外来代码会更容易。
答案 2 :(得分：2)
通过转移到MVC来忘记提高应用程序的速度。我发现了易于代码重用的最大好处。一旦转移到MVC，就不会依赖于数据的表示或实际数据的存储。
例如，您可以编写一个服务于.jsp页面的servlet作为您的表示层，并在第二天将Web服务作为另一个表示层写入现有的模型和控制器。如果您想要或需要切换DBMS，那就明智了。由于访问模型与其他所有内容完全分开，因此您只需重新编写数据访问对象，即可以Controller控制的方式返回数据。
通过将问题分成3个不同的部分，您还可以促进真正的单元测试。您的表示层可以不使用模型或控制器进行测试，反之亦然。
另一方面，我经常觉得MVC的缩写是不准确的。每当我看到它时，我认为它是 View-＆gt; Controller-＆gt; Model 。表示层中永远不会有DAO代码，模型中永远不会有表示逻辑。财务主任被迫充当中间人。
答案 3 :(得分：0)
在3层将表示与业务和数据访问分开的情况下，MVC是一种表示层模式，它进一步将模型（数据）与视图（屏幕）和控制器（输入）分开。
没有选择3层/ 3层的MVC。使用它们。