在阅读有关 MVC 框架的在线讨论时，我听到很多来自 Java/.NET 开发人员的评论指向 PHP 项目，如 Cake、Code Igniter 和 Symfony，“这些都是聪明的 hack，但不是真正的 MVC”。
那么，是什么让某个东西成为“真正的”MVC 框架？即 .NET 或 Java MVC 框架的示例与 Cake、Code Igniter、Symfony 等不同，这些不同的东西是什么？只是 PHP 缺乏需要引导程序的强制面向对象，还是其他原因？
我知道为什么 PHP 语言“很烂”，我对 MVC 实现和/或使用的差异更感兴趣。
MVC 的想法是将应用程序架构解耦为三个独立的层，并允许这些层中的每一层使用不同的实现而不影响其他层。主要区别在于业务逻辑（模型）和表示（视图）。
许多 PHP 框架尝试使用 Ruby on Rails 的“自以为是的软件”理念，因此模型和视图的正确运行要求两者都符合特定的实现。也就是说，类必须以某种方式命名，项目中的文件必须根据某种目录结构组织，视图脚本中的符号必须遵循约定等。
这使得很难独立替换每一层的不同实现，这违背了 MVC 将层彼此分离的目标。
这里有几个问题可以帮助您了解您的框架是否良好和真实。
即使您不编写单元测试，这也适用。
您应该能够独立于框架编写与 MVC 相关的代码。当您的应用程序从框架接收一些输入时，它应该是具有已知接口的对象，没有具体的类。
问题是，真正的MVC 框架对架构本身没有（或非常有限）影响。充其量，它只会为应用程序调用提供一种清晰而简单的方法来访问您的 MVC 三元组。并且可能为您提供便利......而不是限制和约束。
您应该能够扩展框架提供的任何类。并且应该很容易理解您必须实现哪个功能。
如果“事情刚刚发生” ，这将变得非常困难。这通常指向框架代码中的全局状态。以静态方法或全局/静态变量的形式。
你能找到你的控制器在哪里以及如何被执行吗？通常不会那么容易。这个神秘的点通常在对象图中很深。有时甚至在扩展课程中。
这种情况使您很难更改执行控制器的环境。它还对控制器方法的外观施加了严格的规则。
这一切都回到了重点，真正的 MVC 框架应该增强开发过程而不是限制您的选择。
身份验证和授权似乎是开发的一个独立方面，但实际上，在 MVC 的上下文中，它往往有点棘手。
许多框架都有一些身份验证/授权基础设施。这是一项重复性的任务，我们都把它做死了，因此 - 它是框架可以提供的功能的一个很好的候选者。
但关键在于：他们中的大多数人都试图将授权放在你的控制器中，而且他们对如何调整它非常挑剔。这是另一个限制。
归根结底就是这个。对于任何框架，都不能仅仅为了添加登录功能而重写每个控制器。即使您忽略了 OCP 的违规行为，这也会增加您意外忘记某些内容的风险。
..我的两分钱
Cake 和大多数“MVC”框架都可以称为“被动视图”MVC。这是一篇很棒的文章解释： http: //www.martinfowler.com/eaaDev/PassiveScreen.html
您可能会发现此wiki 页面很有用。
真正的 MVC 框架没有 M(odel) 层。CakePHP 和朋友们有一些聪明的类来访问数据库，他们称之为模型，将大部分数据处理留给控制器。
那是错的。模型应该做所有的数据处理（它可以使用帮助数据库类），控制器应该是用户/网页和模型之间的网关。大多数时候，模型是一个简单的 PHP 对象，不遵守任何规则，因此框架无法指定这些规则。
顾名思义，框架旨在支持结构——在这种情况下是您的应用程序。您会看到的大多数框架的共同（和可悲）的事情是它们本身就变成了强加的结构，决定了它们自己分离业务逻辑、表示、路由/控制的方式。您会看到应用程序代码看起来需要整个团队来维护您一年前编写的内容。目标似乎是框架中功能的丰富性。不，这不对。这是关于让程序员自由决定应该分离应用程序的哪些组件以及应该分离的位置 - 只要任务可以分配给具有自己专业知识的个人工作组。
是否应该在模型、视图和控制之间进行分离——顺便说一下，它们必须在某个地方以某种方式相互通信——模糊或区别应该由解决方案架构师决定。
有时人们需要退后一步，看看现实生活中的“框架”，数字世界正是从这个“框架”中得到这个词的。尽管无穷无尽的在线选项扭曲了这个词以适应个人议程并贬低其他系统，但这可能有助于解释它的含义。
框架应该在您工作的每个领域都为您提供帮助。
因此，如果您只有一个投资组合页面 - 那么您只需要一小部分工具。如果您启动下一个 Facebook，那么您的“框架”将大不相同。
JavaServer Faces 是一个非常好的 MVC 全栈框架。它具有良好的视图组件、带有托管 bean 的良好控制器，并且您可以为模型创建业务类。