【问题标题】:Is WordPress MVC compliant? [closed]WordPress MVC 是否兼容? [关闭]
【发布时间】:2011-02-20 21:03:57
【问题描述】:

有些人认为 WordPress 是一个博客平台,有些人认为它是一个 CMS,有些人认为 WordPress 是一个开发框架。无论是哪一个,问题仍然存在。 WordPress MVC 是否兼容?

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

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

谢谢 ;)

【问题讨论】:

  • MVC 是一种架构设计模式,独立于软件类型。任何博客平台、CMS 或开发框架都可以是 MVC,这取决于它的架构方式。
  • eKek0,这样想。但是,嘿,应该有一些不符合 MVC 的 CMS 和框架的示例,即它们的核心架构根本不是 MVC。你能想到吗?

标签: model-view-controller wordpress


【解决方案1】:

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

WordPress MVC 解决方案:

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

【讨论】:

  • MVC 的想法似乎很不受欢迎——几乎所有的想法都被否决了。
【解决方案2】:

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

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

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

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

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

其中的每一部分都不是一个对象,但这并没有减少 MVC。您可以更改 WP 核心,而无需(必须)更改有关主题的任何内容。同样,只要您使用像“get_pages()”这样的内置函数,那么只要这些函数仍然返回正确的数据,模型和数据库表就可以更改。因此,模型独立于视图,控制器也是独立的(除非视图添加控制器逻辑以完成比核心通常所做的更多工作)。

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

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

只要名称、参数等保持不变(或者只是添加了新的),那么关注点的分离就可以保持,并且可以在不影响其他人的情况下进行更改。

它不是一个超级干净的 MVC 版本,(尤其是当涉及到钩子时),但在基本层面上它从那里开始。

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

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

【讨论】:

  • 我在这里评论我自己的作品。 Wordpress 本身不是 MVC。事实上,它开箱即用的设计模式绝对不是 MVC。通常,我使用 page.php 之类的视图文件作为脚本的控制器类型位(准备变量、业务逻辑等,并在必要时与 DB 对话),然后加载单独的视图文件,例如页面视图.php。我已经这样做了一段时间了,我忘记了普通的 WP 代码是多么复杂,直到我看到那里过于复杂的东西。
【解决方案3】:

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

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

【讨论】:

    【解决方案4】:

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

    【讨论】:

    • 看起来不错,但最新的代码更新已经 2 年了。这个项目还活着吗?
    【解决方案5】:

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

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

    恰当的例子:WordPress 不是 MVC。

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

    “但我喜欢 MVC!”

    我也是!事实上,我去年在一个或多或少模仿 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 实现了事件驱动的设计模式,因此即使您最终尝试实现 MVC,您仍然必须使用钩子系统。

    如果您不小心,最终可能会在没有真正完成工作的情况下尝试构建完美的架构,从而最终发现自己在软件的氛围中如此高涨,以至于您实际上已经成为了架构宇航员. 所以你是说避免设计模式?

    一点也不!设计模式是有目的的,因为最重要的是,它们基本上为我们提供了以前和常见问题的解决方案。使用它们!

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

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

    来自http://tommcfarlin.com/wordpress-and-mvc/的礼貌(并完全复制:P)

    【讨论】:

      【解决方案6】:

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

      我把它放在一起主要是为了减少在 WordPress 上构建应用程序所需的控制器代码量,结果是一个在 WordPress 中运行的非常快速有效的框架。这些模型基于PHP Activerecord,现有 WordPress 数据类型包含 8 个模型,包括 Post、PostMeta、User、UserMeta、Term 等。借助 activerecord 库,对数据进行建模非常容易,到目前为止,我非常喜欢使用这个框架。

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

      【讨论】:

      • 哇,布莱恩干得好!很酷的框架,我试试看。
      【解决方案7】:

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

      【讨论】:

        【解决方案8】:

        我最近在创建一个使用简单视图控制器系统的插件时大吃一惊,并且非常喜欢结果,所以我将模板内容分开to its own repo。它提供基于对象的控制器,将变量本地传递给 PHP 模板、模板片段(模板中的模板)和组件(带有自己的子控制器的模板片段)。全部在两个小班!

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

        【讨论】:

          【解决方案9】:

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

          【讨论】:

          • WordPress 远非“易于学习”才能正确使用它,而 IMO 因为它不使用 MVC 模式。它融合了多年来引入的许多技术和设计模式,遗留兼容性阻碍了任何重大改革。代码库可能是一个谈判的雷区,“懒惰者”会遇到很多问题,就像任何框架一样。
          • 与 Zend 或其他适当的框架(如 CI)相比,它很容易学习......即使命名约定也有很大的改进空间。加油!!
          • 你是对的 - WP 不是 MVC。我刚开始使用 WP,第一眼看到一个非常著名的主题的模板文件就吓到我了——这看起来像 10 年前人们使用的编码风格——html、php、css 混合在一起。业务逻辑和屏幕表示在一个地方。不要误会我的意思 - WP 非常好,但它需要重写恕我直言。
          • @Hexodus 查看数据库,你会更加惊讶:)
          • 您不必在视图级别编写逻辑。但可以肯定的是,它确实鼓励了这种方法。如果您使用像 post/page.php 这样的普通视图文件作为更多的业务控制器,而不是在处理完所有业务逻辑后加载不同的视图文件,它会变得更干净。这是我一段时间以来一直在做的事情。
          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2015-08-04
          • 1970-01-01
          • 2021-04-19
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多