[Erledigt] Eigenes CMS auf MVC umrüsten

Heyho,

ich rüste zurzeit mein CMS auf mehr oder weniger MVC um

Nun geh ich folgendermaßen ran:

- index.php hier wird ein pageloader erstellt, sprich er holt sich das Llayout rendert es, Plugins werden geladen sowie der Autoloader inialisiert

- Ich habe ein Plugin geschrieben "createResources" hier wird eine Db anbindung sowie eine Cacheanbindung erstellt, Translate / View / Config Objekt erstellt danach werden diese Objekte in die von vielen Seiten gehaste Registry gespeichert....

- Meine Controller erben einen baseController in dem werden die Objekte aus der Registry geholt und vereinfach so vefügbar gemacht : $this->view = registry view;

Ich wollte Fragen ob das absoluter Blödsinn ist, es für so einen Aufbau eine bessere Alternative als Registry gibt (ich sehe mit meinen Anfängerniveo noch wenig Nachteile von der Registry).

Ordnerstruktur:

index.php
classes
- db
- registry
- view
....
content
- module
-- news
--- models
--- mappers
--- controllers
--- views
--- images
--- styles
--- forms
- boxen
- sites
plugins
- getRessources
helpers
- actionhelpers
- layouthelper
layouts
configs
languages




Ich verwende kein Framework also mehr oder weniger mein kleines

mfg

[Seldon]

Für globale Objekte bietet sich natürlich eine Registry an, wenn du aber flexibel sein und über leicht testbare Klassen verfügen möchtest, solltest du dir Dependency Injection anschauen, d.h. deine Config/View/etc. werden von außen eingefügt, z.B. mittels Konstruktor:

class BaseController
{
    protected $view;
    protected $config;
    protected $translation;

    public function __construct(ViewInterface $view, ConfigInterface $config, TranslationInterface $translation)
    {
        $this->view = $view;
        $this->config = $config;
        $this->translation = $translation;
    }
} 

Zum Injecten gibt es auch fertige Klassen, die dir das ein Stück weit wieder abnehmen (z.B. Stubbles IOC).

[Dominik]

Beim lesen..

[nikosch]

Nein. Du solltest lesen, was geschrieben wird.

[Dominik]

Okay das hab ich nun verstanden aber den ersichtlichen Vorteil sehe ich noch nicht wirklich

Könntet ihr mir vllt ohne viel Fachsprache zeigen wie er das mit

 flexibel sein und über leicht testbare Klassen

meint ?

[Seldon]

Ok, dann versuche ich das mal zu erklären, aber bitte korrigiert mich, so gut kenne ich mich da jetzt nicht aus .

Zu flexibel ein Zitat aus dem Wikipedia-Artikel:

In einem klassisch aufgebauten OO-System ist jedes Objekt selbst dafür zuständig, seine Abhängigkeiten, also benötigte Objekte und Ressourcen, zu erzeugen und zu verwalten. Dafür muss jedes Objekt einige Kenntnisse seiner Umgebung mitbringen, die es zur Erfüllung seiner eigentlichen Aufgabe normalerweise nicht benötigen würde. Insbesondere muss es, um die entsprechenden Objekte erzeugen zu können, ihre konkrete Implementierung kennen.

Das heißt: Deine Controller-Klassen müssen wissen, wie die Registry aufgebaut ist und wie sie funktioniert. Wenn du eines Tages bestimmte Controller eine XML-Datei ausliefern lassen möchtest, tauschst du einfach die Darstellung aus, verwendest also eine XML-basierte View (wenn du stets gegen Schnittstellen programmierst, haben alle deine Views die gleichen Methoden, können also problemlos ausgetauscht werden).

Wenn du das innerhalb der Controller lösen willst, müssen entweder alle Controller wissen, dass sie sich eine XML-View holen sollen

$this->view = $this->registry->getXMLView(); 

oder du musst für diese Controller eine zweite Registry anlegen, und das, obwohl du ja nur eine einzige Komponente ausgetauscht hast.

Mit DI regelst du das an deinem Einstiegspunkt (da wo du vermutlich deine Registry erzeugst). Die Abhängigkeit (Controller benötigt XML-View) wird so spät wie möglich festgelegt.

Zu testbar: Du wirst eine ganze Menge Klassen haben, die trotz großer Vorsicht nun mal voneinander abhängig sind. Da kann eine kleine Änderung an der Wirkungsweise einer Methode fatale Folgen haben. Weil es sehr mühsam wäre, das alles von Hand zu überprüfen, gibt es Unit-Tests, mit denen du deine Klassen automatisiert testen kannst.

Beim Test der Controller bräuchtest du wieder eine andere View, eine Art Dummy, die absolut gar nichts macht, denn schließlich willst du nur die Funktionsfähigkeit der Controller überprüfen. Und auch da ist es einfacher, diese von außen zu injecten, als erst durch den ganzen Code zu gehen, um rauszufinden, was die Klasse alles an Objekten benötigt.

Weiterführende Informationen:

Inversion of Control | PHP hates me - Der PHP Blog
PHP Dependency Injection (englisch)