是否符合 WordPress MVC？

Is WordPress MVC compliant?

提问by kovshenin

Some people consider WordPress a blogging platform, some think of it as a CMS, some refer to WordPress as a development framework. Whichever it is, the question still remains. Is WordPress MVC compliant?

有些人认为 WordPress 是一个博客平台，有些人认为它是一个 CMS，有些人将 WordPress 称为一个开发框架。不管是什么，问题仍然存在。是否符合 WordPress MVC？

I've read the forums and somebody asked about MVC about three years ago. There were some positive answers, and some negative ones. While nobody knows exactly what MVC is and everybody thinks of it in their own way, there's still a general concept that's present in all the discussions.

我读过论坛，大约三年前有人问过 MVC。有一些肯定的答案，也有一些否定的。虽然没有人确切地知道 MVC 是什么，每个人都以自己的方式思考它，但在所有讨论中仍然存在一个通用概念。

I have little experience with MVC frameworks and there doesn't seem to be anything about the framework itself. Most of the MVC is done by the programmer, am I right? Now, going back to WordPress, could we consider the core rewrite engine (WP_Rewrite) the controller? Queries & plugin logic as the model? And themes as the view? Or am I getting it all wrong?

我对 MVC 框架几乎没有经验，而且框架本身似乎没有任何内容。大多数MVC是由程序员完成的，对吗？现在，回到 WordPress，我们可以将核心重写引擎 (WP_Rewrite) 视为控制器吗？查询和插件逻辑作为模型？和主题作为视图？还是我都弄错了？

Thanks ;)

谢谢 ;）

采纳答案by user239974

Wordpress itself is not architected in MVC, but one can build very MVC oriented themes and plugins within the framework. There are several tools which can help:

Wordpress 本身不是在 MVC 中构建的，但是可以在框架内构建非常面向 MVC 的主题和插件。有几种工具可以提供帮助：

WordPress MVC solutions:

WordPress MVC 解决方案：

• Churro: @ wordpress.org/extend/plugins/churro
• Tina-MVC: @ wordpress.org/extend/plugins/tina-mvc
• Plugin Factory: @ wordpress.org/extend/plugins/plugin-factory
• MVCPress: http://mozey.wordpress.com/2007/01/22/mvcpress-screenshots/#comment-3634(abandoned, but interesting ideas)

• 丘罗：@ 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 （废弃但有趣的想法）

MVC threads on WordPress.org Ideas and Trac:

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

• 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(more on XSL than MVC)
• http://core.trac.wordpress.org/ticket/12354(on MVC in widgets)

• 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）

回答by Brenn

Wordpress is kinda-sorta MVC. If anything it is a pull-type MVC layout, where the View 'pulls' data from the model. It does this in a very proceedural way, instead of using lots of different objects, but this actually makes the front end templates easier to write in a lot of ways.

Wordpress 有点像 MVC。如果有的话，它是一个拉式 MVC 布局，其中视图从模型“拉”数据。它以一种非常程序化的方式做到这一点，而不是使用许多不同的对象，但这实际上使前端模板在很多方面更容易编写。

This also gives the views some degree of controller logic (thus the kinda-sorta MVC).

这也为视图提供了某种程度的控制器逻辑（因此有点像 MVC）。

Lets run this down: Wordpress gets a URL. The wordpress core acts as a controller and determines what initial queries to run of the database, and by extension, what view should be loaded (category view, single post or page view, etc). It then packages that INTIAL query response and sends it to the view file.

让我们分析一下：Wordpress 获取一个 URL。wordpress 核心充当控制器，并确定要运行数据库的初始查询，以及应加载的视图（类别视图、单个帖子或页面视图等）。然后它打包该 INTIAL 查询响应并将其发送到视图文件。

That view file CAN be a strict display only file OR it can request additional information/queries beyond the built in one. This is the pull-type of the MVC, where the view pulls data from the model instead of the controller 'pushing' data from the model into the view.

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

Thus, when the view sees code to load a sidebar or widget area, it asks for that information. However, what widgets should be there is determined by the controller, which looks at the model for what widgets are in the sidebar, and then selects those that are set to show on the current page, and returns those to the view.

因此，当视图看到加载侧边栏或小部件区域的代码时，它会询问该信息。然而，应该有哪些小部件是由控制器决定的，它会查看侧边栏中有哪些小部件的模型，然后选择那些设置为显示在当前页面上的小部件，并将它们返回给视图。

That each part of that isn't an object doesn't make this any less MVC. You can alter WP core without (necessarily) altering anything about a theme. Similarly, as long as you use built in functions like 'get_pages()' then the model and the database tables could change as long as those functions still returned the right data. So, the model is independent of the view, and the controller is independent as well (except when the view adds controller logic to do more than the core normally does).

它的每个部分都不是对象并不会使 MVC 变得更少。您可以更改 WP 核心，而无需（必须）更改有关主题的任何内容。同样，只要您使用诸如“get_pages()”之类的内置函数，只要这些函数仍返回正确的数据，模型和数据库表就可以更改。所以，模型独立于视图，控制器也是独立的（除非视图添加控制器逻辑来做比核心通常做的更多的事情）。

While you COULD have a model object holding a number of methods and stuff like WPModel::get_pages('blah blah'), and contain everything that way, there is still fundamental separation of concerns.

虽然您可以拥有一个模型对象，其中包含许多方法和诸如 WPModel::get_pages('blah blah') 之类的东西，并以这种方式包含所有内容，但仍然存在基本的关注点分离。

View: template files Controller: WP core Model: the various functions that handle specific data handling.

视图：模板文件控制器：WP 核心模型：处理特定数据处理的各种功能。

As long as the names, arguments, etc, stay the same (or just have new ones added) then separation of concerns is maintained and one can be altered without disturbing the others.

只要名称、参数等保持不变（或者只是添加了新的），那么关注点的分离就会保持不变，并且可以在不干扰其他的情况下改变一个。

It isn't a super-clean version of MVC, (especially when hooks get involved), but at a basic level it starts there.

它不是 MVC 的超级干净版本（尤其是当涉及到钩子时），但在基本级别上它从那里开始。

And being proceedural about it isn't a bad thing IMO. A request from a website is pretty inherently proceedural: it is a process with a clear beginning and end, and just needs a procedure to process the request, get data, package it, then die. You can set up those steps with objects and object methods and OOP layouts (which would make some things easier) or you can just write alot of function calls and separate them out that way. Class members like private variables are lost that way but depending on the needs of the application... you might not care.

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

There is no one-grand-way to do development, and WP sits at like 20% of websites so it is doing something right. Probablysomething to do with not making people have to learn/memorize complex class hierarchies to get the database to answer the question 'what pages are child of page x?' and deal with that data. Could you make it that easy with OOP? yes, but if Joomla is any example of how hard it is to implement a complex custom website with OOP, then WP is FAR easier and quicker, and time is money.

没有一种通用的开发方式，WP 占据了大约 20% 的网站，所以它正在做一些正确的事情。 可能与不让人们必须学习/记住复杂的类层次结构才能让数据库回答“哪些页面是页面 x 的子页面？”的问题有关。并处理这些数据。你能用 OOP 让它变得那么容易吗？是的，但是如果 Joomla 是使用 OOP 实现复杂的自定义网站是多么困难的任何例子，那么 WP 会更容易、更快，而且时间就是金钱。

回答by Daff

As already mentioned in the comments, MVC is an architectural design pattern, not a specific framework, and no, Wordpress doesn't follow the MVC pattern.

正如评论中已经提到的，MVC 是一种架构设计模式，而不是一个特定的框架，不，Wordpress 不遵循 MVC 模式。

There is a separation of views (templates) from the programming logic, but only in the frontend, not in the admin panel and a general separation of views and application logic is not inevitably MVC. An implementation of the MVC pattern usually assumes some kind of object oriented programming paradigm behind it and Wordpress is mainlyimplemented in a procedural way, with plain SQL queries in the PHP functions, therefore not having an actual model either.

视图（模板）与编程逻辑是分离的，但仅在前端，而不是在管理面板中，并且视图和应用程序逻辑的一般分离并非不可避免的 MVC。MVC 模式的实现通常在其背后假定某种面向对象的编程范式，而 Wordpress主要以过程方式实现，在 PHP 函数中使用纯 SQL 查询，因此也没有实际模型。

回答by Dave Amphlett

Just to update this with more recent information for people hitting this from search engines - the wp-mvc plugin http://wordpress.org/extend/plugins/wp-mvc/goes a long way to creating a mvc framework for plugin development. You can find out more here: http://wpmvc.org/documentation/70/tutorial/

只是为了让人们从搜索引擎中获得更多最新信息来更新它 - wp-mvc 插件http://wordpress.org/extend/plugins/wp-mvc/在创建用于插件开发的 mvc 框架方面大有帮助。您可以在此处了解更多信息：http: //wpmvc.org/documentation/70/tutorial/

回答by Rahul Balakrishna

One of the topics that periodically crops up in discussions as it relates to WordPress is the idea of WordPress and MVC.

与 WordPress 相关的讨论中定期出现的主题之一是 WordPress 和 MVC 的想法。

But the thing is that MVC is not the silver bullet of web development that we try to make it out to be. Yes, it's an awesome design pattern, and I personally think that it fits the web application model like a glove, but not every framework or platform implements that design pattern.

但问题是 MVC 并不是我们试图让它成为的 Web 开发的灵丹妙药。是的，这是一个很棒的设计模式，我个人认为它像手套一样适合 Web 应用程序模型，但并不是每个框架或平台都实现了这种设计模式。

Case in point: WordPress is not MVC.

举个例子：WordPress 不是 MVC。

And that's okay. I think we need to leave the desire of trying to shoehorn it into our projects aside especially when the pattern WordPress provides is not only sufficient, but works well when leveraged correctly.

没关系。我认为我们需要将尝试将其硬塞到我们的项目中的愿望搁置一旁，尤其是当 WordPress 提供的模式不仅足够，而且在正确利用时效果很好。

“But I Love MVC!”

“但我喜欢 MVC！”

So do I! In fact, I spent the last year working on a project that more-or-less mimicked the MVC architecture. A high-level example of MVC.

我也是！事实上，去年我在一个或多或少模仿 MVC 架构的项目上工作。MVC 的高级示例。

A high-level example of MVC.

MVC 的高级示例。

For example:

例如：

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.

Finally, a set of rewrite rules gave the application a clean set of predictable URLs in the format of /people/update/1 or /people/all. What Pattern Does WordPress Implement?

最后，一组重写规则为应用程序提供了一组干净的可预测 URL，格式为 /people/update/1 或 /people/all。WordPress 实现了什么模式？

WordPress implements the event-driven architecture (of which there are several variations such as the Observer Pattern).

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

In short, you can conceptually think of this as the following:

简而言之，您可以从概念上将其视为以下内容：

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

Not too complicated, is it? A high-level example of event-driven patterns A high-level example of event-driven patterns

不会太复杂吧？事件驱动模式 的高级示例 事件驱动模式的高级示例

When you begin to think in terms of the paradigm in which it works rather than trying to make it work the way that you want it to work, it's liberating. It helps to solve problems much more easily.

当你开始根据它工作的范式而不是试图让它以你想要的方式工作时，它就是解放。它有助于更​​轻松地解决问题。

The bottom line is this: WordPress implements the event-driven design pattern, so even if you end up trying to implement MVC, you're still going to have to utilize the hook system.

底线是这样的：WordPress 实现了事件驱动的设计模式，因此即使您最终尝试实现 MVC，您仍然必须使用钩子系统。

If you're not careful, you can end up trying to craft the perfect architecture without actually getting your work done, and thus end up finding yourself so high up in the atmosphere of software that you've effectively become an architecture astronaut. So You're Saying Avoid Design Patterns?

如果您不小心，您最终可能会尝试制作完美的架构而实际上并未完成您的工作，从而最终发现自己在软件的氛围中如此高，以至于您实际上已成为一名架构宇航员。所以你是说避免设计模式？

Not at all! Design Patterns serve a purpose because, above all else, they basically give us solutions to previously and commonly solved problems. Use them!

一点也不！设计模式服务于一个目的，因为最重要的是，它们基本上为我们提供了以前和普遍解决的问题的解决方案。使用它们！

But the point I'm trying to make is that we don't need to try to force things to fit pattern just because we like the pattern. That's not their purpose. Instead, leverage the primary pattern that your platform of choice implements – in our case, it's an event-driven pattern – and then implement patterns where they fit (such as dependency injection or something like that).

但我想说明的一点是，我们不需要仅仅因为我们喜欢这个模式就试图强迫事情符合模式。那不是他们的目的。相反，利用您选择的平台实现的主要模式——在我们的例子中，它是一个事件驱动模式——然后在它们适合的地方实现模式（例如依赖注入或类似的东西）。

Otherwise, it's like trying to put your foot in a glove.

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

Courtesy (and totally copied :P) from : http://tommcfarlin.com/wordpress-and-mvc/

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

回答by Brian Zeligson

Just to add to the list of options, (I'm admittedly biased as the author,) swpMVCis a fully featured, lightweight MVC framework, inspired by Rails, Sinatra, Express, and FuelPHP. It's thoroughly documented, and while I have used and enjoyed wp-mvc, I wanted something where the models were able to populate views themselves, including form controls for interacting with said models.

只是添加到选项列表中，（我承认作为作者有偏见）swpMVC是一个功能齐全的轻量级 MVC 框架，其灵感来自 Rails、Sinatra、Express 和 FuelPHP。它有完整的文档记录，虽然我已经使用并喜欢wp-mvc，但我想要一些模型能够自己填充视图的东西，包括用于与所述模型交互的表单控件。

I put this together largely to reduce the amount of controller code required to put together an app on top of WordPress, and the result is a very fast and effective framework that runs inside WordPress. The models are based on PHP Activerecordand 8 models are included for existing WordPress data types, including Post, PostMeta, User, UserMeta, Term, and a few more. Modeling data is very easy thanks to the activerecord library, and I've enjoyed working with this framework immensely thus far.

我把它们放在一起主要是为了减少在 WordPress 上组装应用程序所需的控制器代码量，结果是一个在 WordPress 内部运行的非常快速和有效的框架。这些模型基于PHP Activerecord，并且包含 8 个针对现有 WordPress 数据类型的模型，包括 Post、PostMeta、User、UserMeta、Term 等。多亏了 activerecord 库，建模数据变得非常容易，到目前为止，我非常喜欢使用这个框架。

Also ships with underscore PHP and PHP Quick Profiler (as seen in FuelPHP.)

还附带下划线 PHP 和 PHP Quick Profiler（如 FuelPHP 中所示。）

回答by rodrigo-silveira

RokkoMVCis a micro MVC framework built especially for WordPress. The project is meant to simplify AJAX functionality in WordPress applications, as well as bringing in all the other benefits of using models, views, and controllers to your theme.

RokkoMVC是一个专门为 WordPress 构建的微型 MVC 框架。该项目旨在简化 WordPress 应用程序中的 AJAX 功能，并为您的主题带来使用模型、视图和控制器的所有其他好处。

回答by halfer

I had a bash recently at creating a plugin that makes use of a simple view-controller system, and quite liked the results, so I separated the template stuff out to its own repo. It offers object-based controllers, passing variables locally to PHP templates, template fragments (templates within templates) and components (template fragments with their own sub-controller). All in two tiny classes!

我最近在创建一个使用简单视图控制器系统的插件时遇到了 bash，并且非常喜欢结果，所以我将模板内容分离到它自己的 repo 中。它提供基于对象的控制器，在本地将变量传递给 PHP 模板、模板片段（模板中的模板）和组件（带有自己的子控制器的模板片段）。全部分为两个小班！

Of course, I wrote this code thinking that no other WP developer had considered the problem before ;-).

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

回答by lokers

It's far from mvc, there is no kinda-sorta thing like some people say, it's either MVC or not... The fact that you write logic on the view level doesn't qualify it as a mvc framework. The reason people use it - it's easy to learn, you don't need to be hardcore php programmer, they're lazy.

它与 mvc 相去甚远，并没有像某些人所说的那样，它要么是 MVC，要么不是......事实上，您在视图级别编写逻辑并不能将其视为 mvc 框架。人们使用它的原因 - 它很容易学习，你不需要成为铁杆 php 程序员，他们很懒惰。