Ankündigung

Einklappen
Keine Ankündigung bisher.

Front-Controller und MVC Verständnisprobleme

Einklappen

Neue Werbung 2019

Einklappen
X
Einklappen
  • Seite von 1
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge
Vorherige Weiter
  • #1

    Front-Controller und MVC Verständnisprobleme

    Grundsätzlich unterteilen sich meine derzeitigen Gedanken in zweite konkrete Problemstellungen, für die ich scheinbar keine eigene Lösung zu finden vermag. Einleitend dazu möchte ich anmerken, dass ich den Sinn und Zweck von sowohl des MVC-Patterns, als auch des Front-Controllers im Groben und Ganzen verstanden habe. Nun möchte ich meine beiden Probleme konkretisieren und hoffe auf eure Anregungen.

    Integration des Front-Controllers in die MVC-Architektur
    Ich habe mir einen Front-Controller, sowie eine HttpRequest- und eine HttpResponse-Klasse aus dem Buch "PHP Design Patterns von O'Reilly" abgeleitet und realisiert. Der Front-Controller agiert mit der Anfrage (Request) und der Antwort (response). Mein Front-Controller unterstützt zur Zeit folgendes URL-Layout:

    index.php?modul=index&action=login
    Der Front-Controller funktioniert in diesem Kontext einwandfrei - Der Index-Controller wird instanziert und die Methode login() wird ebenfalls erfolgreich entnommen und ausgeführt. Das eigentliche Problem liegt meiner Auffassung darin, dass ich nicht wirklich weiß, wie der besagte Front-Controller anständig in die MVC-Architektur integriert werden kann. Ist das überhaupt eine akzeptable Vorgehensweise?

    Hinweis: Mit der Verschachtelung von Modulen werden ich mich gegebenfalls noch beschäftigen, jedoch muss ich dazu erstmal die fundamentale Implementierung vollkommen durchdringen.

    Weiterreichung von Objekten
    Laut meinem Wissensstand kennt der Controller in den meisten Fällen das Modell und die Präsentationsschicht. Dieses Problem spaltet sich in zwei konkrete Fragestellungen auf:
    1. Wie gestaltet sich eine automatische Zuordnung beider Komponenten (Modell, View) in Hinblick auf den Controller? Unter welchen Gesichtspunkten wird eine konkrete Instanzierung besagter Klassen durchgeführt?
    2. Wie werden Objekte aus externen Klassen - zum Beispiel Benutzer - in das 3-Schichten-System integriert? Mir ist durchaus bewusst, dass die wohl beste Möglichkeit die Dependency-Injection darstellt, jedoch liegt darin mein Problem. Welcher Mechanismus instanziert - die für das Modul - erforderlichen und zugeschnittenen Klassen (Benutzer etc.)? Der Front-Controller dürfte eigentlich keine konkreten Objekte instanzieren, da die Module in diesem Zusammenhang abstrakt behandelt werden müssen.


    Ich hoffe inständig auf eure Hilfe und bin dankbar über jede Hilfe.
    Stichworte: -
  • #2
    Warum unterstützt dein FrontController ein URL-Layout? Im Request steckt doch die Information über Controller, Action, usw. FrontController und URL kennen sich garnicht.

    Den Rest habe ich mir ehrlich gesagt nicht durchgelesen, weil das Thema MVC, FrontController, etc. hier bis zum - Entschuldigung - vergasen diskutiert wurde.
    "[URL="http://www.youtube.com/watch?v=yMAa_t9k2VA&feature=youtu.be&t=25s"]Mein Name ist Lohse, ich kaufe hier ein.[/URL]"

    Kommentar

    • #3
      Zuletzt geändert von Anyone; 03.11.2009, 20:52.
      Auf die Lösung des ersten Problems bin ich nun gekommen, jedoch bereitet mir das zweite Problem große Schwierigkeiten und soweit ich das einschätzen kann, wurde dieses konkrete Problem noch nie in dieser Form vorgestellt?

      Der Front-Controller sollte abstrakt gehalten werden, so dass keine konkreten Instanzierungen vorgenommen werden. Die Instanzen dürfen in den einzelnen Komponenten der Schichten nicht willkürlich instanziert werden, da das sonst dem Ziel der losen Kopplung (Dependency Injection) widersprechen würde.

      Beispiel:

      Model 1 benötigt eine Datenquelle (egal ob eine Datenbank- oder File-Klasse) und Model 2 benötigt eine Datenquelle und ein Userobjekt. Modell 3 benötigt eine vollkommen andere Klasse.


      Wie kann ein solches Problem dynamisch gelöst werden?

      Edit: Kann diese Problematik vielleicht mit Templates gelöst werden? Ein Template würde demnach meiner Auffassung zufolge beispielsweise in dieser Art aufgebaut sein:

      HTML-Code:
      <required instances>
   <database host="..." ...></database>
   <user ...></user>
</required instances>
      Jedoch erscheint mir diese Lösung auch zu statisch zu sein...

      Kommentar

      • #4
        Hi,

        da das sonst dem Ziel der losen Kopplung (Dependency Injection) widersprechen würde.
        Lose Kopplung ist nicht gleich DI! DI ist ein Mittel um lose Kopplung ("loose coupling") zu realisieren. Du musst aufpassen, dass du nicht Konzepte mit expliziten Maßnahmen verwechselst, das kann zu problematischen Designs führen.

        Model 1 benötigt eine Datenquelle (egal ob eine Datenbank- oder File-Klasse) und Model 2 benötigt eine Datenquelle und ein Userobjekt. Modell 3 benötigt eine vollkommen andere Klasse.
        Wie bereits beschrieben führt das zu einer deutlichen Überbewertung des Models und sollte unterlassen werden. Für die Daten-Acquise ist ein eigener Service, dem diese Informationen injiziert werden deutlich besser geeignet.

        Jedoch erscheint mir diese Lösung auch zu statisch zu sein...
        Ich würde das abstrakter lösen: DIServiceManager des APF. Dieser kennt abstrakte Services (also keine konkreten database/user-Services) und nutzt weitere Service-Objekte um dieses zu initialisieren. Weiterhin ist die Möglichkeit gegeben, "einfache" Konfigurationen in Form von Direktiven vorzunehmen. So kannst du beispielsweise den Namen der zu verwendenden Datenbank-Verbindung injizieren. Das reicht beim APF eigentlich schon, da Datenbank-Verbindungen über den ConnectionManager schon ausreichend abstrahiert sind.

        Da du scheinbar immer wieder an verschiedenen Punkten konzeptionell hängen bleibst, würde ich dir langsam aber sicher dazu raten, ein fertiges Produkt zu nutzen, das dir die geforderten Möglichkeiten bietet. Alles andere scheint mir nicht ausreichend Zielführend zu sein. Hast du das APF mal unter diesen Anforderungen getestet?
        Viele Grüße,
        Dr.E.

        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        1. Think about software design [B]before[/B] you start to write code!
        2. Discuss and review it together with [B]experts[/B]!
        3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
        4. Write [I][B]clean and reusable[/B][/I] software only!
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

        Kommentar

        Vorherige Weiter
        Lädt...
        X