MVC Repository Pattern

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • MVC Repository Pattern

    Hallo,

    ich steh grad auf dem Schlauch, glaube ich.

    Ich habe eine Klasse, mit der ich konkrete Abfragen auf einen Webservice mache, nennen wir sie mal ZkClient. Die hat im wesentlichen die Methoden
    • DomDocument getEntryDocument()
    • string sendCommand (int $actionType, int $uuid, string $data = "")


    Dann gibt es noch die ModelKlassen Administration, District und Department die in dieser Reihenfolge eine hierarchische Struktur darstellen. D. h. eine Administration enthält mehrere Districts, ein District enthält mehrere Departments.

    Daher soll es möglich sein, die enthaltenen Unterobjekte abzurufen, also Administration::getDistricts() und District::getDepartments(). Um diese Informationen abzurufen, muss irgendwann per ZkClient::sendCommand() etwas angefragt werden. Dafür wollte ich jetzt ein Repository bauen.

    Das Problem ist, dass alle Abfragen so lazy wie möglich stattfinden. Das heißt, wenn ich aus dem Repository eine Administration hole, werden die zugehörigen Districts noch nicht dort reingefüllt, sondern sollen erst nachgeladen werden, wenn man Administration::getDistricts() aufruft. Somit muss der Klasse Administration zumindest das Repository bekannt sein, oder wäre das eine Design-Schwachstelle? Konkret gefragt: Gibt es eine bessere Lösung als diese hier?

    PHP-Code:
    class Administration extends StructuralUnit {
        
    // ...
        
    public function __construct (IRepository $repo) {}
        
    // ...
        
    public function getDistricts () {
            return 
    $this->repo->getSubUnitsOf($this);
        }
        
    // ...
    }

    class 
    District extends StructuralUnit {
        
    // ...
        
    public function __construct (IRepository $repo) {}
        
    // ...
        
    public function getDepartments () {
            return 
    $this->repo->getSubUnitsOf($this);
        }
        
    // ...
    }

    class 
    Department extends StructuralUnit {
        
    // ...
        
    public function __construct (IRepository $repo) {}
        
    // ...
    }

    interface 
    IRepository {
        public function 
    getSubUnitsOf (StructuralUnit $parentUnit null);
    }

    class 
    ZkRepository implements IRepository {
        
    // ...
        
    public function __construct (ZkClient $client) {}
        
    // ...

    Danke und Gruß,

    Amica
    Zuletzt geändert von AmicaNoctis; 17.06.2011, 22:26.
    [COLOR="DarkSlateGray"]Hast du die [COLOR="DarkSlateGray"]Grundlagen zur Fehlersuche[/color] gelesen? Hast du Code-Tags benutzt?
    Hast du als URL oder Domain-Beispiele example.com, example.net oder example.org benutzt?
    Super, danke!
    [/COLOR]

  • #2
    Baumförmige Datenstruktur

    Hallo Amica,

    Du hast eine hierarchische (baumfoermige) Datenstruktur. Stell Dir vor Du haettest jetzt noch Sub-Departments, Sub-Sub-Departments, ...

    Dann muesstest Du bei Deinem Ansatz jeweils neue Klassen (bzw. Funktionen fuer Dein Interface IRepository) einfuehren. Es liegt also naeher, so zu arbeiten, dass der Code prinzipiell mit jeder Hierarchietiefe zurechtkommt. Haeufig fuehrt ein solcher abstrakter Ansatz auch automatisch zu Codevereinfachungen.

    Kommentar


    • #3
      Zitat von mephisto111 Beitrag anzeigen
      Stell Dir vor Du haettest jetzt noch Sub-Departments, Sub-Sub-Departments, ...
      Danke für deine Antwort, aber darum geht es nicht. Die Klassennamen hab ich mir ausgedacht, um es zu vereinfachen. Die Hierarchie ist außerdem streng festgelegt und unveränderlich weswegen das Composite Pattern gerade nicht zum Einsatz kommen soll, da es diese strenge Typisierung aufweichen würde. Hab den Code trotzdem mal geändert und das verallgemeinert.

      Worum es geht: Ist es vertretbar, dass die Modelklassen eine Instanz der Repositoryklasse speichern oder darf die Assoziation nur in die andere Richtung erfolgen? Gibt es einen besseren Weg, das zu erledigen, aber einen, bei dem die Modelklasse nicht a priori vollständig befüllt sein muss, also immer noch lazy access möglich ist?
      Zuletzt geändert von AmicaNoctis; 17.06.2011, 22:25.
      [COLOR="DarkSlateGray"]Hast du die [COLOR="DarkSlateGray"]Grundlagen zur Fehlersuche[/color] gelesen? Hast du Code-Tags benutzt?
      Hast du als URL oder Domain-Beispiele example.com, example.net oder example.org benutzt?
      Super, danke!
      [/COLOR]

      Kommentar


      • #4
        Da inzwischen der größte Teil der User, deren Meinung ich besonders schätze, diesen Thread gelesen hat, ohne irgendwas in der Art „Wie kannst du nur…?“ oder „Warum machst du es nicht so, dass …“ zu hinterlassen, gehe ich davon aus, dass der Entwurf so bleiben kann. Danke für euer zustimmendes Schweigen
        [COLOR="DarkSlateGray"]Hast du die [COLOR="DarkSlateGray"]Grundlagen zur Fehlersuche[/color] gelesen? Hast du Code-Tags benutzt?
        Hast du als URL oder Domain-Beispiele example.com, example.net oder example.org benutzt?
        Super, danke!
        [/COLOR]

        Kommentar

        Lädt...
        X