是WordPress的MVC兼容？

有些人认为WordPress是一个博客平台，有些人认为它是一个CMS，有些人把WordPress称为开发框架。 无论如何，这个问题依然存在。 是WordPress的MVC兼容？

我已经阅读了三年前的论坛，有人问到MVC。 有一些积极的答案，一些消极的答案。 虽然没有人确切地知道MVC是什么，每个人都以他们自己的方式来思考，但是在所有讨论中仍然存在一个普遍的概念。

我几乎没有MVC框架的经验，似乎没有关于框架本身的任何事情。 大多数的MVC是由程序员完成的，对吗？ 现在，回到WordPress，我们可以考虑核心重写引擎（WP_Rewrite）的控制器？ 查询和插件逻辑作为模型？ 和主题一样的看法？ 还是我得到这一切都错了？

谢谢 ;）

Answer 1

WordPress本身并不是在MVC中架构的，但是可以在框架中构build面向MVC的主题和插件。 有几个工具可以帮助：

WordPress MVC解决scheme：

• Churro：@ wordpress.org/extend/plugins/churro
• Tina-MVC：@ wordpress.org/extend/plugins/tina-mvc
• 插件工厂：@ wordpress.org/extend/plugins/plugin-factory
• MVCPress： http ://mozey.wordpress.com/2007/01/22/mvcpress-screenshots/#comment-3634（放弃，但有趣的想法）

WordPress.org上的MVC线程Ideas and Trac：

• http://wordpress.org/extend/ideas/topic/mvc-plugin-framework
• http://wordpress.org/extend/ideas/topic/complete-reestructuring
• http://wordpress.org/extend/ideas/topic/rewrite-wordpress-using-mvc
• http://wordpress.org/extend/ideas/topic/wordpress-theme-revamp （更多关于XSL的比MVC）
• http://core.trac.wordpress.org/ticket/12354 （在小部件中的MVC）

Answer 2

WordPress的是一种MVC。 如果有的话，它是一个拉式MVC布局，其中视图从模型中“拉出”数据。 它以一种非常有序的方式来完成，而不是使用许多不同的对象，但是这实际上使得前端模板更容易以多种方式编写。

这也给了一定程度的控制器逻辑的意见（因此有点不同MVC）。

让我们运行这个：WordPress获取一个URL。 wordpress的核心作为一个控制器，并确定什么样的初始查询运行的数据库，扩展，应该加载什么样的视图，单个职位或页面视图等。 然后打包该INTIAL查询响应并将其发送到视图文件。

该视图文件可以是严格的仅显示文件，或者可以请求超出内置的信息/查询。 这是MVC的拉式types，其中视图从模型中提取数据，而不是从控制器中将数据从模型中推送到视图中。

因此，当视图看到代码加载一个侧栏或小部件区域，它要求的信息。 但是，控件应该在哪个小部件中，控制器会查看边栏中的小部件的模型，然后select在当前页面上显示的小部件，然后将这些小部件返回到视图。

这不是一个对象的每个部分不会使这个MVC更less。 你可以改变可湿性粉剂核心，而不必（一定）改变主题的任何东西。 同样，只要你使用像get_pages（）这样的内置函数，只要这些函数仍然返回正确的数据，模型和数据库表就可以改变。 所以，这个模型是独立于视图的，并且控制器也是独立的（除了视图添加控制器逻辑的function比核心更多的时候）。

虽然你可以拥有一个模型对象，像WPModel :: get_pages（'blah blah'）一样拥有许多方法和东西，并且包含了所有的东西，但仍然存在根本性的关注点分离。

查看：模板文件控制器：WP核心模型：处理特定数据处理的各种function。

只要名称，论点等保持不变（或者只是添加新的名称），就可以保持关注点的分离，并且可以修改一个，而不会打扰其他的。

这不是一个超级干净的MVC版本（特别是当涉及钩子的时候），但是从基本的层面开始。

关于这个事情，国际海事组织并不是一件坏事。 来自网站的请求本质上是一个过程：它是一个开始和结束的过程，只需要一个过程来处理请求，获取数据，打包，然后死亡。 你可以用对象和对象方法和OOP布局来设置这些步骤（这可以使一些事情变得更容易），或者你可以写很多的函数调用并将它们分开。 像私有variables这样的类成员会丢失这种方式，但取决于应用程序的需求…您可能不在乎。

没有一个伟大的发展方式，WP坐在像20％的网站，所以它正在做一件正确的事情。 可能有些事情不要让人们学习/记忆复杂的类层次结构，以便让数据库回答“哪些页面是页面x的子页面？”的问题。 并处理这些数据。 你能用OOP简单吗？ 是的，但是如果Joomla是用OOP实现一个复杂的自定义网站是多么困难的例子，那么WP更容易，更快，而且时间就是金钱。

Answer 3

正如在评论中已经提到的，MVC是一个架构devise模式，而不是一个特定的框架，不，WordPress不遵循MVC模式。

视图（模板）与编程逻辑是分离的，但只有在前端，而不是在pipe理面板中，视图和应用程序逻辑的一般分离不一定是MVC。 MVC模式的实现通常采用某种面向对象的编程模式，而Wordpress 主要是以过程方式实现的，在PHP函数中使用普通的SQL查询，因此也没有实际的模型。

Answer 4

只是为了更新这个更新的信息，让人们从search引擎中得到这个信息 – wp-mvc插件http://wordpress.org/extend/plugins/wp-mvc/为插件开发创build了一个mvc框架。; 你可以在这里find更多： http : //wpmvc.org/documentation/70/tutorial/

Answer 5

只是添加到选项列表（我承认有偏见作者，） swpMVC是一个function齐全，轻量级的MVC框架，灵感来自Rails，Sinatra，Express和FuelPHP。 这是完全logging，而我已经使用和享受wp-mvc ，我希望模型能够自己填充视图的东西，包括与所述模型交互的表单控件。

我把它放在一起主要是为了减less将应用程序置于WordPress之上所需的控制器代码数量，其结果是一个在WordPress中运行的非常快速有效的框架。 这些模型基于PHP Activerecord ，包括Post，PostMeta，User，UserMeta，Term等在内的8种模型。 build模数据非常简单，这要归功于activerecord库，而且我非常喜欢这个框架。

还附带下划线PHP和PHP快速剖析器（如FuelPHP中所示）。

Answer 6

定期讨论与WordPress相关的主题之一就是WordPress和MVC。

但事情是，MVC不是我们试图做到的Web开发的灵丹妙药。 是的，这是一个非常棒的devise模式，我个人认为它像手套一样适合Web应用程序模型，但并不是每个框架或平台都实现了这种devise模式。

例如：WordPress不是MVC。

这没关系。 我认为我们需要抛开试图把它放到我们的项目之外的欲望，特别是当WordPress提供的模式不仅足够的时候，而且当正确使用时运作良好。

“但是我爱MVC！”

我也是！ 事实上，我在去年花了一个项目，或多或less地模仿了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实现什么模式？

WordPress实现了事件驱动的体系结构（其中有几个变种，如观察者模式）。

总之，你可以从概念上将这个想象为：

 Things happen when WordPress is processing information. You can register your own function to fire when these things happen. 

不是太复杂，是吗？ 事件驱动模式的高级示例 事件驱动模式的高级示例

当你开始按照其工作范式来思考，而不是试图按照你想要的方式工作时，它就是解放的。 它更容易解决问题。

底线是这样的：WordPress实现事件驱动的devise模式，所以即使你最终试图实现MVC，你仍然将不得不利用钩子系统。

如果你不小心，最终可能会试图创build一个完美的架构，而没有真正完成你的工作，从而最终发现自己在软件的氛围中如此高尚，以至于你已经成为一名build筑宇航员。 所以你说避免devise模式？

一点也不！ devise模式是为了达到目的，因为最重要的是，它们基本上为我们解决了以前常见的问题。 使用它们！

但是我想说的一点是，我们不需要试图强迫事物适应模式，只是因为我们喜欢模式。 那不是他们的目的。 相反，利用您select的平台实现的主要模式（在我们的例子中，这是一个事件驱动的模式），然后在适合的模式（例如dependency injection或类似的东西）中实现模式。

否则，就像试图把你的脚放在手套里一样。

礼貌（并完全复制：P）从： http : //tommcfarlin.com/wordpress-and-mvc/

Answer 7

RokkoMVC是专门为WordPress构build的微型MVC框架。 该项目旨在简化WordPress应用程序中的AJAXfunction，并将模型，视图和控制器的所有其他优点带入您的主题。

Answer 8

我最近创build了一个使用简单的视图 – 控制器系统的插件，并且非常喜欢这个结果，所以我把这些模板分离出来， 放到了自己的仓库中 。 它提供基于对象的控制器，将variables本地传递到PHP模板，模板片段（模板内的模板）和组件（带有自己的子控制器的模板片段）。 所有在两个小class！

当然，我写了这个代码，认为没有其他的WP开发者之前考虑过这个问题;-) 。

Answer 9

这远离mvc，没有什么比一些人所说的那种东西，不是MVC就是MVC。事实上，你在视图层次上编写逻辑并不能将其视为mvc框架。 人们使用它的原因 – 这很容易学习，你不需要是硬核PHP程序员，他们是懒惰的。