Home-Produkte-Testarea-Kontakt-Datenschutz-Aktualisiert: 28-Apr-2011
< Voriger Tag   Nächster Tag >

Donnerstag, 28. April 2011

PHP: Framework - Dependency Injection

Bei MVC soll sich das Model mit $this->view->render() selbst darstellen können. Andererseits soll es im RuBisCO-Framework Daten unter beliebigen Namen speichern können - inklusive $view, was im obigen Fall schon belegt ist. Die Frage ist, ob im RuBisCO-Framework das Model nur die eigentlichen Daten enthält oder auch zusätzliche vom Framerwork festgelegte Eigenschaften, deren Namen für das Framework reserviert sind wie $app, $view, $controller, $log, ...?

Nur Model

  • Beliebige Namen können für die Eigenschaften benutzt werden
  • Keine reservierten Namen/Eigenschaften wie $app, $view, $log, $database, ...
  • view($model)-Aufruf durch Controller

Model mit ->view...

  • Für Framework reserviert: $app, $view, $log, $database, ...
  • Neue reservierte Eigenschaften inkompatible mit vorhandenen Model
  • Einfacher Aufruf von $this->view->render()

Model nur mit ->app

  • Nur $app für das Framework reserviert
  • Aufwendiger Aufruf: $this->app->log->debug()

Reservierte Namen mit Prefix

  • $_view, $rView, $rbsView, §view
  • Neue reservierte Eigenschaften kompatible mit vorhandenen Model
  • Einfacher Aufruf: $this->rbsLog->debug()
  • Namen die mit rbs anfangen können nicht für das Model benutzt werden

Model holt Dependencies selbst

public function save() {
    $app = Application::getInstance();

    $app->database->query(...);
}


public function save() {
    $database = Database::getInstance();
    $log      = Log::getInstance();

    $database->query(...);
}


public function write() {
    list($app, $view, $log) = App::getAllInstances();
    list($app, $view)       = App::getInstances('app', 'view');

    $log->debug();
}
  • Model kann Namen frei wählen
  • (Viel) zusätzlicher Programmcode in jeder Methode notwendig

Dependencies als Hilfsfunktionen

namespace database;

function query() {
    static $cfg      = null;
    static $database = null;


    if(is_null($cfg)) {
        $cfg = Config::getInstance();

        $database = $cfg->databaseClass::getInstance();
    }

    $database->query();
}

require_once 'database.php';


public function save() {
    databasequery();
    logdebug();
}
  • Model kann Namen frei wählen
  • Einfacher Aufruf
  • Funktionen müssen sich Objekt holen
  • Objekte in den Hilfsfunktionen sind global, kein individueller Controller u.ä. möglich - entspricht Klassenvariablen, -Methoden

Model legt Dependency Injection fest

class Model {
    public $inject = array('model' => 'mvc->model',
                           'log'   => '_log');
}
  • Model kann Namen frei wählen
  • Abhängig vom Model verschiedene Namen für gleiche Dinge

Fazit

Model mit reserviertem ->view, ...: Sehr unpraktisch wenn eine neue Version des Frameworks zusätzliche Eigenschaften braucht.

Model nur mit ->app: Aufwendiger Aufruf.

Reservierte Namen mit Prefix: Nur Prefix reserviert. Weiterhin einfacher Aufruf.

Model holt Dependencies selbst: In jeder Methode zusätzlicher Programmcode notwendig.

Dependencies als Hilfsfunktionen: Nur geeignet für Objekte, die für alle gleich sind ($database, $log) - entspricht Klassenvariablen, -Methoden. Unterschiedliche Objekte wie $controller, $view sind damit nicht möglich.

Model legt Dependency Injection fest: Zusätzliche Konfiguration. Unterschiedliche Bezeichnungen für gleiche Dinge.

Selbst wenn der Controller das Anzeigen übernimmt, braucht das Model immer noch $database, $log, ... selbst. Für sinnvoll halte ich daher den Prefix, die Hilfsfunktionen und die Konfiguration der Injections durchs Model.

Der Prefix sperrt nur Namen, die mit dem Prefix beginnen. Schön wäre es $view für Framework-Eigenschaften und §name für Model-Eigenschaften benutzen zu können.

Mit Hilfsfunktionen wie logdebug() oder Klassenmethoden ist die Benutzung einfach und das Framework braucht keine reservierte Eigenschaften. Die Namen der Klassen werden in der Konfiguration festgelegt aber individuelle Objekte wie View, Model, Controller müssen vom aufrufenden Objekt verwaltet werden.

Beim Festlegen der Injections durchs Model oder einer entsprechenden Konfiguration bleibt die Programmierung wie gehabt aber abhängig vom Model gibt es für gleiche Dinge unterschiedliche Namen. Beim Hinzufügen von Framework-Eigenschaften muss in den bestehenden Klassen die Injections-Konfiguration erweitert werden.

Die Hilfsfunktionen sind eine interessante Variante aber das Festlegen der Injections durchs Model halte ich für die beste Variante - eventuell kombiniert mit dem Prefix. Unterschiedliche Namen für gleiche Dinge dürfte nicht so häufig vorkommen. Wichtig ist, dass der Aufruf einfach ist und eine neue Version des Frameworks zusätzliche Injections anbieten kann, ohne dass es Namenskollisionen mit bereits vorhandenen Objekteigenschaften gibt.

Beispiel

In framework/labs/injection/.

[Direktlink]

< Voriger Tag   Nächster Tag >

  RSS V0.91

<April 2011 >
    010203
04050607080910
11121314151617
18192021222324
252627282930 

Home-Produkte-Testarea-Kontakt-Datenschutz-Aktualisiert: 28-Apr-2011
(C) 2000-2018 by Sven Drieling