Php 比MVC更适合web应用的体系结构？

我一直在为我的新工作学习Zend及其MVC应用程序结构，发现使用Zend让我感到困扰，原因我无法完全理解。然后，在我的学习过程中，我遇到了一些关于MVC和web应用程序的文章，如和。播客中的那个家伙提出了一个非常好的反对MVC作为web应用程序体系结构的理由，并且把很多困扰我的东西都钉在了我的头上

---

然而，问题仍然存在，如果MVC不是一个真正适合web应用程序的工具，那么它是什么呢

根据我的经验，在为web开发时，MVC体系结构所带来的好处远远超过了它的成本和明显的开销

对于一个刚开始使用复杂MVC框架的人来说，花额外的精力将三个层分开，并对什么属于哪里有一个良好的感觉，这可能有点让人望而生畏（有些事情是显而易见的，有些事情可能是非常边缘的，往往是讨论的好话题）。我认为从长远来看，这一成本是值得的，特别是如果您希望您的应用程序能够在一段合理的时间内增长或得到维护

我曾经遇到过这样的情况：创建一个新的API以允许其他客户端连接到现有web应用程序的成本非常低，这是因为层之间有很好的分离：业务逻辑根本没有连接到演示文稿，所以很简单

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

如果真的有其他很好的方法来替代这个范例的话。。。我对答案很感兴趣

---

对不起，这是一堵小小的文字墙

我想这取决于你个人的想法。洋红非常成功地使用了MVC，它使添加新功能或修改现有功能变得相当容易

---

当然，如果你想让事情变得相当简单，那么使用MVC架构可能会有些过头

这完全取决于您的编码风格。这里有一个秘密：用PHP编写经典的MVC是不可能的。

任何声称你能做到的框架都在欺骗你。事实上，框架本身甚至不能实现MVC——您的代码可以。但我想这不是一个好的营销宣传

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

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

• Model2 MVC：视图正在从模型请求数据，然后决定如何渲染数据以及使用哪些模板。控制器负责更改视图和模型的状态

• MVVM：控制器被交换为ViewModel，它负责视图期望和模型逻辑之间的转换。查看来自控制器的请求数据，控制器将转换请求以便模型能够理解它
  大多数情况下，当您无法控制视图或模型图层时，会使用此选项

• MVP（php框架称之为“MVC”）：演示者从模型中请求信息，收集信息，修改信息，并将其传递给被动视图
  为了探索这种模式，我建议您从开始。它将详细解释这一点

• HMVC（或PAC）：与型号2不同，控制器能够执行子控制器。每个都有自己的M、V和C三元组。您可以获得模块化和可维护性，但付出的代价是性能有所提高

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

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

• 事件驱动体系结构
• n层体系结构

---

然后总是有范例，但是当应用到PHP时，它有一些问题（你不能在PHP中强制转换到一个类，除非有丑陋的黑客）。

这都是首选。我曾经使用过XTemplates和Smarty这样的旧结构，现在我开始使用Codeigniter和Kohona。我非常喜欢它们，它们对我在网络上所做的每一件事都很有效。对于手机应用程序，我可以设置控制器，以实现数据采集所需的功能。在Linux世界和Windows世界中工作，对于构建ASP.NET网站，除了使用MVC之外，我看不到其他构建网站的方法。VisualStudio中的Web应用程序项目仍在使用，但我不希望再使用了。通过VisualStudio的MVC项目非常易于使用和设置。您可以右键单击控制器方法并自动创建视图。每个结构都有好的和坏的，但是开发人员可以根据自己的需要使用任何东西。

我完全支持划分，但正如播客中指出的，MVC似乎不是正确的方法。“视图”是指用户界面中的单个显示元素，而不是整个用户界面。此外，尤其是在Zend中，整个过程似乎过于依赖于magic——如果不使用XDebug之类的工具手动跟踪程序流控制，就很难知道程序流控制下一步将跳转到哪里。这可能只是Zend大量使用单例和注册表的产物。谢谢，这些看起来很有趣。特别是模型2。我将研究这些，看看哪一个看起来最适合我的目标。

“要实现一个经典的MVC，首先需要有持久性模型。”

，这句话推断了什么？持久的重复的