有些人认为WordPress是一个博客平台,有些人认为它是一个CMS,有些人将WordPress称为开发框架.无论哪个,问题仍然存在.WordPress MVC是否合规？
我读过论坛,三年前有人问过MVC.有一些积极的答案,一些是消极的答案.虽然没有人确切知道MVC究竟是什么,并且每个人都以自己的方式对其进行了思考,但仍然存在一个在所有讨论中都存在的一般概念.
我对MVC框架没什么经验,似乎没有关于框架本身的任何内容.大多数MVC都是由程序员完成的,对吗？现在,回到WordPress,我们可以考虑核心重写引擎(WP_Rewrite)控制器吗？查询和插件逻辑作为模型？和主题一样的观点？还是我弄错了？
谢谢 ;)
Wordpress本身并不是在MVC中构建的,但可以在框架内构建非常适合MVC的主题和插件.有几种工具可以帮助:
WordPress MVC解决方案:
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主题思路和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上)
Wordpress有点像MVC.如果它是拉式MVC布局,那么View将从模型中"拉出"数据.它以非常自然的方式执行此操作,而不是使用大量不同的对象,但这实际上使前端模板在很多方面更容易编写.
这也为视图提供了一定程度的控制器逻辑(因此有点类型MVC).
让我们运行它:Wordpress获取一个URL.wordpress核心充当控制器,并确定要运行数据库的初始查询,以及扩展,应加载哪个视图(类别视图,单个帖子或页面视图等).然后它打包INTIAL查询响应并将其发送到视图文件.
该视图文件可以是严格的仅显示文件,也可以请求内置的文件以外的其他信息/查询.这是MVC的pull-type,其中视图从模型中提取数据而不是控制器将数据从模型"推送"到视图中.
因此,当视图看到加载侧边栏或窗口小部件区域的代码时,它会询问该信息.但是,应该在哪些小部件中由控制器确定,控制器查看侧边栏中的小部件的模型,然后选择那些设置为在当前页面上显示的小部件,并将它们返回到视图.
它的每个部分都不是一个对象,这不会使MVC更少.你可以改变WP核心而不必(必然)改变主题的任何内容.同样,只要您使用内置函数(如'get_pages()'),只要这些函数仍返回正确的数据,模型和数据库表就会发生变化.因此,模型独立于视图,并且控制器也是独立的(除非视图添加控制器逻辑以执行比核心通常更多的操作).
虽然你可以拥有一个模型对象,其中包含许多方法和类似WPModel :: get_pages('blah blah')的东西,并且包含所有这些方法,但仍然存在基本的关注点分离.
查看:模板文件控制器:WP核心模型:处理特定数据处理的各种函数.
只要名称,参数等保持不变(或者只添加新的名称),就可以保持关注点的分离,并且可以在不干扰其他问题的情况下改变关注点.
它不是MVC的超级版本(特别是当钩子涉及时),但在基本层面它从那里开始.
并且继续谈论它并不是坏事IMO.来自网站的请求本质上是完全可行的:它是一个具有明确开始和结束的过程,只需要一个过程来处理请求,获取数据,打包,然后死亡.您可以使用对象和对象方法以及OOP布局设置这些步骤(这会使某些事情变得更容易),或者您可以编写大量函数调用并将其分离出来.像私有变量这样的类成员会丢失,但是根据应用程序的需要......你可能不在乎.
没有一个伟大的方式来进行开发,WP占据了20%的网站,所以它正在做正确的事情. 可能与不让人们必须学习/记忆复杂的类层次结构以使数据库回答"页面x的子页是什么页面？"这一问题有关.并处理这些数据.你能用OOP轻松搞定吗？是的,但如果Joomla是使用OOP实现复杂的自定义网站有多么困难的任何一个例子,那么WP就更容易,更快,而且时间就是金钱.
正如评论中已经提到的,MVC是一种架构设计模式,而不是一个特定的框架,不,Wordpress不遵循MVC模式.
视图(模板)与编程逻辑分离,但仅在前端,而不是在管理面板中,视图和应用程序逻辑的一般分离不一定是MVC.MVC模式的实现通常假设它背后有某种面向对象的编程范例,而Wordpress 主要以过程方式实现,在PHP函数中使用纯SQL查询,因此也没有实际模型.
只是为了让人们从搜索引擎中获取更多信息来更新这一点 - wp-mvc插件http://wordpress.org/extend/plugins/wp-mvc/为创建用于插件开发的mvc框架做了大量工作.你可以在这里找到更多信息:http://wpmvc.org/documentation/70/tutorial/
与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,你仍然必须使用钩子系统.
如果你不小心,你最终可能会尝试制作完美的架构,而不会真正完成你的工作,因此最终发现自己在软件的氛围中如此之高,以至于你已经成为一名建筑宇航员.所以你说避免设计模式？
一点也不!设计模式有一个目的,因为最重要的是,它们基本上为我们提供了解决以前和常见问题的解决方案.使用它们!
但我想说的是,我们不需要试图强迫事物适应模式只是因为我们喜欢这种模式.那不是他们的目的.相反,利用您选择的平台实现的主要模式 - 在我们的例子中,它是一个事件驱动的模式 - 然后实现它们适合的模式(例如依赖注入或类似的东西).
否则,就像试着把脚放在手套里一样.
礼貌(完全复制:P)来自:http://tommcfarlin.com/wordpress-and-mvc/
京公网安备 11010802040832号 | 京ICP备19059560号-6 