Ist WordPress MVC-konform? [closed]

Einige Leute betrachten WordPress als Blogging-Plattform, andere als CMS, wieder andere beziehen sich auf WordPress als Entwicklungs-Framework. Was auch immer es ist, die Frage bleibt immer noch. Ist WordPress MVC-konform?

Ich habe die Foren gelesen und jemand hat vor etwa drei Jahren nach MVC gefragt. Es gab einige positive Antworten und einige negative. Während niemand genau weiß, was MVC ist und jeder auf seine eigene Weise darüber denkt, gibt es immer noch ein allgemeines Konzept, das in allen Diskussionen vorhanden ist.

Ich habe wenig Erfahrung mit MVC-Frameworks und es scheint nichts über das Framework selbst zu geben. Der größte Teil des MVC wird vom Programmierer durchgeführt, habe ich recht? Nun, zurück zu WordPress, könnten wir die Core Rewrite Engine (WP_Rewrite) als Controller betrachten? Abfragen & Plugin-Logik als Vorbild? Und Themen wie die Aussicht? Oder verstehe ich das alles falsch?

Vielen Dank 😉

WordPress selbst ist nicht in MVC aufgebaut, aber man kann innerhalb des Frameworks sehr MVC-orientierte Themes und Plugins bauen. Es gibt mehrere Tools, die helfen können:

WordPress MVC-Lösungen:

• Churo: @ 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 (verlassene, aber interessante Ideen)

MVC-Threads auf WordPress.org 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 (mehr zu XSL als zu MVC)
• http://core.trac.wordpress.org/ticket/12354 (auf MVC in Widgets)

WordPress ist irgendwie MVC. Wenn überhaupt, handelt es sich um ein MVC-Layout vom Pull-Typ, bei dem die Ansicht Daten aus dem Modell „zieht“. Es tut dies auf eine sehr prozedurale Weise, anstatt viele verschiedene Objekte zu verwenden, aber das macht es tatsächlich einfacher, die Frontend-Vorlagen auf viele Arten zu schreiben.

Dies gibt den Ansichten auch ein gewisses Maß an Controller-Logik (daher die Art von MVC).

Lassen Sie uns das herunterfahren: WordPress erhält eine URL. Der WordPress-Kern fungiert als Controller und bestimmt, welche anfänglichen Abfragen der Datenbank ausgeführt werden sollen und welche Ansicht geladen werden soll (Kategorieansicht, Einzelpost- oder Seitenansicht usw.). Dann packt er diese INTIAL-Abfrageantwort und sendet sie an die Ansichtsdatei.

Diese Ansichtsdatei KANN eine reine Anzeigedatei sein ODER sie kann zusätzliche Informationen/Abfragen über die eingebaute hinaus anfordern. Dies ist der Pull-Typ des MVC, bei dem die Ansicht Daten aus dem Modell abruft, anstatt dass der Controller Daten aus dem Modell in die Ansicht „pusht“.

Wenn die Ansicht also Code zum Laden einer Seitenleiste oder eines Widgetbereichs sieht, fragt sie nach diesen Informationen. Welche Widgets vorhanden sein sollten, wird jedoch vom Controller bestimmt, der das Modell nach Widgets in der Seitenleiste durchsucht und dann diejenigen auswählt, die auf der aktuellen Seite angezeigt werden sollen, und diese an die Ansicht zurückgibt.

Dass jeder Teil davon kein Objekt ist, macht dies nicht weniger MVC. Sie können den WP-Kern ändern, ohne (notwendigerweise) etwas an einem Thema zu ändern. Ebenso können sich das Modell und die Datenbanktabellen ändern, solange Sie eingebaute Funktionen wie ‘get_pages()’ verwenden, solange diese Funktionen noch die richtigen Daten zurückgeben. Das Modell ist also unabhängig von der Ansicht, und der Controller ist ebenfalls unabhängig (außer wenn die Ansicht Controller-Logik hinzufügt, um mehr zu tun, als der Kern normalerweise tut).

Während Sie ein Modellobjekt haben KÖNNTEN, das eine Reihe von Methoden und Sachen wie WPModel::get_pages(‘blah blah’) enthält und alles auf diese Weise enthält, gibt es immer noch eine grundlegende Trennung der Bedenken.

Ansicht: Vorlagendateien Controller: WP-Kern Modell: die verschiedenen Funktionen, die eine spezifische Datenbehandlung handhaben.

Solange die Namen, Argumente usw. gleich bleiben (oder nur neue hinzugefügt werden), wird die Trennung der Anliegen aufrechterhalten und eines kann geändert werden, ohne die anderen zu stören.

Es ist keine supersaubere Version von MVC (insbesondere wenn Hooks involviert sind), aber auf einer grundlegenden Ebene beginnt es dort.

Und prozedural zu sein, ist meiner Meinung nach keine schlechte Sache. Eine Anfrage von einer Website ist von Natur aus prozedural: Es ist ein Prozess mit einem klaren Anfang und Ende und benötigt nur eine Prozedur, um die Anfrage zu verarbeiten, Daten zu erhalten, sie zu verpacken und dann zu sterben. Sie können diese Schritte mit Objekten und Objektmethoden und OOP-Layouts einrichten (was einige Dinge einfacher machen würde) oder Sie können einfach viele Funktionsaufrufe schreiben und sie auf diese Weise trennen. Klassenmitglieder wie private Variablen gehen auf diese Weise verloren, aber je nach den Anforderungen der Anwendung … ist es Ihnen vielleicht egal.

Es gibt keinen einheitlichen Weg für die Entwicklung, und WP befindet sich auf etwa 20 % der Websites, also macht es etwas richtig. Wahrscheinlich etwas damit zu tun, dass die Leute keine komplexen Klassenhierarchien lernen/auswendig lernen müssen, damit die Datenbank die Frage beantwortet: “Welche Seiten sind untergeordnete Seiten von Seite x?” und mit diesen Daten umgehen. Könnten Sie es mit OOP so einfach machen? Ja, aber wenn Joomla ein Beispiel dafür ist, wie schwierig es ist, eine komplexe benutzerdefinierte Website mit OOP zu implementieren, dann ist WP VIEL einfacher und schneller, und Zeit ist Geld.

Wie bereits in den Kommentaren erwähnt, ist MVC ein architektonisches Entwurfsmuster, kein bestimmtes Framework, und nein, WordPress folgt nicht dem MVC-Muster.

Es gibt eine Trennung von Views (Templates) von der Programmierlogik, aber nur im Frontend, nicht im Admin-Panel und eine generelle Trennung von Views und Anwendungslogik ist nicht zwangsläufig MVC. Eine Implementierung des MVC-Musters setzt normalerweise eine Art objektorientiertes Programmierparadigma dahinter voraus, und WordPress ist es hauptsächlich prozedural implementiert, mit einfachen SQL-Abfragen in den PHP-Funktionen, daher auch kein tatsächliches Modell.

Eines der Themen, das regelmäßig in Diskussionen im Zusammenhang mit WordPress auftaucht, ist die Idee von WordPress und MVC.

Aber die Sache ist die, dass MVC nicht die Wunderwaffe der Webentwicklung ist, als die wir es darzustellen versuchen. Ja, es ist ein großartiges Designmuster, und ich persönlich denke, dass es wie angegossen zum Webanwendungsmodell passt, aber nicht jedes Framework oder jede Plattform implementiert dieses Designmuster.

Ein typisches Beispiel: WordPress ist nicht MVC.

Und das ist in Ordnung. Ich denke, wir müssen den Wunsch, es in unsere Projekte einzubauen, beiseite lassen, insbesondere wenn das von WordPress bereitgestellte Muster nicht nur ausreichend ist, sondern auch gut funktioniert, wenn es richtig eingesetzt wird.

„Aber ich liebe MVC!“

Ich auch! Tatsächlich habe ich das letzte Jahr damit verbracht, an einem Projekt zu arbeiten, das mehr oder weniger die MVC-Architektur nachahmt. Ein High-Level-Beispiel für MVC.

Ein High-Level-Beispiel für MVC.

Zum Beispiel:

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.

Schließlich gab eine Reihe von Rewrite-Regeln der Anwendung einen sauberen Satz vorhersagbarer URLs im Format /people/update/1 oder /people/all. Welches Muster implementiert WordPress?

WordPress implementiert die ereignisgesteuerte Architektur (von der es mehrere Variationen wie das Observer Pattern gibt).

Kurz gesagt, Sie können sich das konzeptionell wie folgt vorstellen:

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

Nicht zu kompliziert, oder? Ein allgemeines Beispiel für ereignisgesteuerte Muster

Ein allgemeines Beispiel für ereignisgesteuerte Muster

Wenn Sie beginnen, in Begriffen des Paradigmas zu denken, in dem es funktioniert, anstatt zu versuchen, es so funktionieren zu lassen, wie Sie es möchten, ist es befreiend. Es hilft, Probleme viel einfacher zu lösen.

Das Fazit ist folgendes: WordPress implementiert das ereignisgesteuerte Designmuster. Selbst wenn Sie also versuchen, MVC zu implementieren, müssen Sie immer noch das Hook-System verwenden.

Wenn Sie nicht aufpassen, können Sie versuchen, die perfekte Architektur zu erstellen, ohne Ihre Arbeit tatsächlich zu erledigen, und sich so in der Software-Atmosphäre wiederfinden, dass Sie praktisch zum Architektur-Astronauten werden. Sie sagen also, Designmuster vermeiden?

Gar nicht! Design Patterns erfüllen einen Zweck, weil sie uns vor allem Lösungen für zuvor und häufig gelöste Probleme liefern. Benutze sie!

Aber der Punkt, den ich zu machen versuche, ist, dass wir nicht versuchen müssen, Dinge dazu zu zwingen, sich an Muster anzupassen, nur weil uns das Muster gefällt. Das ist nicht ihr Zweck. Nutzen Sie stattdessen das primäre Muster, das Ihre bevorzugte Plattform implementiert – in unserem Fall ist es ein ereignisgesteuertes Muster – und implementieren Sie dann Muster, wo sie passen (z. B. Abhängigkeitsinjektion oder ähnliches).

Ansonsten ist es, als würde man versuchen, den Fuß in einen Handschuh zu stecken.

Mit freundlicher Genehmigung (und vollständig kopiert :P) von : http://tommcfarlin.com/wordpress-and-mvc/

Nur um dies mit neueren Informationen für Leute zu aktualisieren, die von Suchmaschinen darauf stoßen – das wp-mvc-Plugin http://wordpress.org/extend/plugins/wp-mvc/ trägt wesentlich dazu bei, ein mvc-Framework für die Plugin-Entwicklung zu erstellen. Hier erfahren Sie mehr: http://wpmvc.org/documentation/70/tutorial/

Nur um die Liste der Optionen zu ergänzen (ich bin zugegebenermaßen als Autor voreingenommen) swpMVC ist ein voll ausgestattetes, leichtes MVC-Framework, inspiriert von Rails, Sinatra, Express und FuelPHP. Es ist gründlich dokumentiert, und während ich verwendet und genossen habe wp-mvcwollte ich etwas, bei dem die Modelle Ansichten selbst füllen können, einschließlich Formularsteuerelementen für die Interaktion mit diesen Modellen.

Ich habe dies hauptsächlich zusammengestellt, um die Menge an Controller-Code zu reduzieren, die erforderlich ist, um eine App auf WordPress zusammenzustellen, und das Ergebnis ist ein sehr schnelles und effektives Framework, das in WordPress ausgeführt wird. Die Modelle basieren auf PHP Activerecord und 8 Modelle sind für vorhandene WordPress-Datentypen enthalten, darunter Post, PostMeta, User, UserMeta, Term und einige mehr. Das Modellieren von Daten ist dank der ActiveRecord-Bibliothek sehr einfach, und ich habe bisher sehr gerne mit diesem Framework gearbeitet.

Wird auch mit Unterstrich PHP und PHP Quick Profiler geliefert (wie in FuelPHP zu sehen).

RokkoMVC ist ein Micro-MVC-Framework, das speziell für WordPress entwickelt wurde. Das Projekt soll die AJAX-Funktionalität in WordPress-Anwendungen vereinfachen und alle anderen Vorteile der Verwendung von Modellen, Ansichten und Controllern in Ihr Design einbringen.