有些人认为WordPress是一个博客平台，有些人把它称为CMS，还有一些人将WordPress称为开发框架。不管怎样，问题仍然存在。WordPress是否符合MVC标准？
我阅读了论坛，大约三年前就有人提出了MVC的问题。有些人持肯定态度，有些人持否定态度。虽然没有人确切知道MVC是什么，每个人都有自己的看法，但在所有讨论中都存在一个普遍的概念。
我对MVC框架的经验很少，而且似乎与框架本身无关。大多数MVC是由程序员完成的，我是对的吗？现在，回到WordPress上，我们能否认为核心重写引擎（WP_Rewrite）是控制器？查询和插件逻辑作为模型？主题作为视图？还是我完全错了？
谢谢 ;)
WordPress有点像MVC架构。它采用了一种拉取式的MVC布局，其中视图从模型“拉取”数据。这种方式是通过过程化的方式实现的，而不是使用许多不同的对象，但这实际上使得前端模板在许多方面更容易编写。
这也赋予了视图某种程度的控制器逻辑（因此是“有点像”MVC）。
让我们来看看：
WordPress获取URL。WordPress核心充当控制器，确定要运行数据库的初始查询，以及由此引申出的要加载的视图（类别视图、单个帖子或页面视图等）。然后，它将打包初始查询响应并发送到视图文件。
该视图文件可以是严格的只显示文件，也可以请求超出内置文件的其他信息/查询。这就是MVC的“拉取式”，其中视图从模型中提取数据，而不是控制器从模型中“推送”数据到视图中。
因此，当视图看到加载侧边栏或小部件区域的代码时，它会请求该信息。然而，哪些小部件应该在那里由控制器决定，控制器查看侧边栏中的小部件，并选择设置为在当前页面显示的小部件，然后将这些返回给视图。
虽然每个部分都不是对象，但这并不会使其MVC变得不重要。您可以更改WP核心而不必（必须）更改主题的任何内容。同样，只要使用内置函数如“get_pages()”，那么模型和数据库表格可以更改，只要这些函数仍然返回正确的数据即可。因此，模型独立于视图，控制器也是独立的（除非视图添加控制器逻辑以执行比核心通常完成的更多操作）。
虽然您可以使用一个包含许多方法和类似WPModel :: get_pages（'blah blah'）的模型对象来包含所有内容，但仍存在基本的关注点分离。
视图：模板文件 控制器：WP核心 模型：处理特定数据的各种功能。
只要名称、参数等保持不变（或只添加新的）则可维护关注点分离，这样更改一个内容时就不会干扰其他内容。这不是 MVC 的超级干净版本（特别是涉及钩子时），但从基本层面上看它始于此。在我看来，以过程为中心并不是什么坏事。网站的请求本质上是过程性的：它是有明确开端和结束的过程，只需处理请求、获取数据、打包数据，然后关闭即可。您可以使用对象和对象方法以及 OOP 布局设置这些步骤（这将使某些内容更容易），或者您可以编写许多函数调用并通过这种方式将它们分开。但这种方式会丢失类成员，例如私有变量。但根据应用程序的需求，您可能并不在意。开发没有一个万能的方法，WP 占据着约 20% 的网站份额，因此它做得很好。可能是因为 WP 不会让人们学习/记忆复杂的类层次结构来回答“哪些页面是页面 x 的子页面？”并处理这些数据。使用 OOP 可以使这一切变得如此简单吗？是的，但如果 Joomla 是实现具有复杂定制网站的难度的任何例子，那么 WP 的难度要小得多，且速度更快，而时间就是金钱。WordPress和MVC的关系是WordPress讨论中经常涉及的话题之一。
但事实是，MVC并不是我们试图让它成为的Web开发的万能钥匙。是的，它是一个很棒的设计模式，我个人认为它非常适合Web应用程序模型，但并非每个框架或平台都实现了这种设计模式。
事实上，WordPress就不是MVC。
这没关系。我认为我们需要把尝试将其强行融入我们的项目的愿望放在一边，特别是当WordPress提供的模式既足够，而且正确使用时效果良好。
“但我喜欢MVC！”
我也是！事实上，我花了去年的时间研究了一个几乎模仿了MVC架构的项目。
下面是MVC的高级示例图：
例如：
Views were implemented using templates
Controllers were implemented by a combination of using function names like create, read, update, destroy, delete, and so on (even though these functions were hooked into the WordPress API
Models were functions also were called to validate and verify data prior to serializing the data. Again, this required that certain functions be hooked into WordPress to achieve the desired result.
最后，一组重写规则使应用程序具有可预测的干净URL格式，例如/people/update/1或/people/all。
WordPress实现了事件驱动架构（其中有几个变体，如观察者模式）。
简而言之，您可以将其概念化为以下内容：
Things happen when WordPress is processing information.
You can register your own function to fire when these things happen.
一个高级的事件驱动模式示例为了更新一下这篇文章，让搜索引擎上的用户获得更多最新信息——wp-mvc插件http://wordpress.org/extend/plugins/wp-mvc/对于创建插件开发的mvc框架有很大帮助。你可以在这里找到更多信息：http://wpmvc.org/documentation/70/tutorial/
除了上述选项外，（我承认有偏见，因为我是作者之一，）swpMVC是一个完整的轻量级MVC框架，受到Rails、Sinatra、Express和FuelPHP的启发。它有详细的文档，虽然我已经使用过并喜欢wp-mvc，但我想要一些东西，其中模型能够自行填充视图，包括用于与这些模型进行交互的表单控件。
我主要编写了这个框架，以减少在WordPress之上构建应用程序所需的控制器代码量，其结果是一个非常快速和有效的框架，可在WordPress内部运行。模型基于PHP Activerecord，并包括8个现有WordPress数据类型的模型，包括文章、文章元数据、用户、用户元数据、术语等。由于activerecord库，建立数据模型非常容易，迄今为止，我非常喜欢使用这个框架。
还附带有underscore PHP和PHP Quick Profiler（如FuelPHP所示）。
RokkoMVC是一个专为WordPress打造的微型MVC框架。该项目旨在简化WordPress应用中的AJAX功能，并将使用模型、视图和控制器带来的所有其他好处引入到您的主题中。
;-)。离MVC差得远，没有所谓的“有点像但又不完全是”的东西，要么是MVC，要么不是... 在视图层级上编写逻辑并不能称之为一个MVC框架。人们使用它的原因在于，它容易学习，不需要成为一名专业的PHP程序员，他们懒得费劲。