架构比 MVC 更适合 Web 应用？答案

【问题标题】：Architecture more suitable for web apps than MVC?架构比 MVC 更适合 Web 应用？
【发布时间】：2011-11-29 03:02:31
【问题描述】：

我一直在为我的新工作学习 Zend 及其 MVC 应用程序结构，但发现使用它让我很困扰，原因我无法完全理解。然后在我的学习过程中，我遇到了诸如 MVC: No Silver Bullet 和 this podcast 等关于 MVC 和 Web 应用程序主题的文章。播客中的那个人很好地反对将 MVC 作为 Web 应用程序架构，并指出了很多困扰我的问题。

但是，问题仍然存在，如果 MVC 真的不适合 Web 应用程序，那是什么？

【问题讨论】：

你能不能写一两句关于播客所说的 MVC 有问题的地方，让这里的读者不必听它就能理解基本的反对意见？我应该也有兴趣:)
播客链接已损坏，无法修复（回程机器中没有任何内容）。它已被this page 取代，但播客的链接也在那里断开。但是，如果您搜索“为什么 MVC 不是应用程序架构”的演讲，您会得到同一个人的 video presentation。

标签： php model-view-controller web-applications architecture

【解决方案1】：

这完全取决于您的编码风格。秘诀如下：用 PHP 编写经典的 MVC 是不可能的。

任何声称可以的框架都是在骗你。现实情况是，框架本身甚至无法实现 MVC——您的代码可以。但我猜这不是一个很好的营销宣传。

要实现经典的 MVC，您首先需要拥有持久模型。此外，Model 应该通知 View 有关更改（观察者模式），这在您的原生 PHP 页面中也是不可能的（如果您使用套接字，您可以做一些接近经典 MVC 的事情，但这对于真实网站是不切实际的）。

在 Web 开发中，您实际上还有 4 个其他受 MVC 启发的解决方案：

Model2 MVC：视图正在从模型中请求数据，然后决定如何呈现它以及使用哪些模板。 Controller 负责改变 View 和 Model 的状态。
MVVM：Controller 被换成了 ViewModel，它负责 View 的期望和 Model 的逻辑之间的转换。查看来自控制器的请求数据，控制器翻译请求以便模型能够理解它。

当您无法控制视图或模型层时，您通常会使用它。
MVP（php 框架称之为“MVC”）：Presenter 从 Model 请求信息，收集、修改信息，然后将其传递给被动 View。

要探索这种模式，我建议您从this publication 开始。会详细解释的。
HMVC（或 PAC）：与 Model2 不同，控制器能够执行子控制器。每个都有自己的 M、V 和 C 三元组。您获得了模块化和可维护性，但付出了一些性能损失。

无论如何。底线是：你还没有真正使用过 MVC。

但如果你厌倦了所有类似 MVC 的结构，你可以研究一下：

事件驱动架构
n 层架构

然后总是有DCI 范式，但它在应用于 PHP 时会出现一些问题（你不能在 PHP 中强制转换为一个类 .. 并非没有丑陋的 hack）。

【讨论】：

谢谢，这些看起来很有趣。模型2，尤其是。我会研究这些，看看哪一个看起来最适合我的目标。
"To implement a classical MVC it would require for you to have persistent Models to begin with."，这句话是什么意思？执着的？重复？没有任何变化？它会推断出"model without side-effects" 还是完全不同的东西？
在经典 MVC 中，视图观察模型（准确地说，是模型层的结构）。当模型的状态发生变化时，视图会请求新的信息。对于“持久模型”，我的意思是模型层的存在都考虑到了应用程序的使用。这在 PHP 中是不可能的，因为当您发送响应时，模型层的实例会被销毁。这是 PHP Share-Nothing 架构的限制。视图无法观察模型层.. 没有什么可观察的了。
看起来很有希望n-Tier architecture
附带说明：有（或多或少）复杂的解决方案可以在 php 中启用持久会话，这反过来又允许我们创建持久模型。这是我熟悉的解决方案：us2.php.net/manual/en/intro.memcache.php

【解决方案2】：

根据我的经验，在为 Web 开发时，您从 MVC 架构中获得的好处远远超过其成本和明显的开销。

对于开始使用复杂的 MVC 框架的人来说，要付出额外的努力来分离三层，并很好地了解什么属于哪里（有些事情很明显，有些事情可能很明显），这可能有点令人生畏边界线，往往是很好的讨论话题）。我认为从长远来看，这种成本是值得的，特别是如果您期望您的应用程序在一段合理的时间内增长或维护。

我曾经遇到过这样的情况，即创建一个新的 API 以允许其他客户端连接到现有的 Web 应用程序的成本极低，这是由于层的良好分离：业务逻辑根本没有连接到演示文稿，所以它是蛋糕。

在当前的 MVC 框架生态系统中，我相信你的里程可能会有很大的不同，因为原理是通用的，但是在 Zend、Django、RoR 和 SpringMVC 之间存在很多差异。

如果真的有其他很好的替代方案可以替代这种范式...我对答案很感兴趣！

对不起，文字的轻微墙！

【讨论】：

我完全赞成划分，但正如播客中指出的那样，MVC 似乎不是正确的方法。 “视图”是用户界面中的一个单独的显示元素，而不是整个用户界面。此外，特别是在 Zend 中，整个事情似乎过于依赖魔法——如果不使用 XDebug 等手动跟踪程序流控制，很难知道接下来会跳转到哪里。不过，这可能只是 Zend 大量使用单例和注册表的产物。

【解决方案3】：

我认为这取决于你个人想要做什么。 Magenta 非常成功地使用了 MVC，它使得添加新功能或修改现有功能变得相当容易。

当然，如果您想使一些事情变得相当简单，那么使用 MVC 架构可能会有点过头了。

【讨论】：

【解决方案4】：

这都是偏好。我曾使用过 XTemplates 和 Smarty 等旧结构，现在转向 Codeigniter 和 Kohona。我非常喜欢它们，它们对我在网络上所做的一切都非常有效。对于电话应用程序，我也可以为执行数据提取所需的功能设置控制器。在 Linux 世界和 Windows 世界中工作，用于构建 ASP.NET 网站除了使用 MVC 之外，我没有看到其他构建网站的方法。 Visual Studio 中的 Web 应用程序项目仍在使用，但我不想再使用了。通过 Visual Studio 的 MVC 项目非常易于使用和设置。您可以右键单击控制器方法并自动创建视图。在每个结构中都有好的和坏的，但开发人员可以使用任何满足他们需求的结构。

【讨论】：