Ankündigung

Einklappen
Keine Ankündigung bisher.

Architektur einer Verwaltungssoftware

Einklappen

Neue Werbung 2019

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

  • #46
    Zunächst freut mich, dass ich durch meine Frage mal wieder leben ins das Thema gebracht habe

    Wieso nicht eine Klasse View und eine Klasse Layout ?
    Wie schon beschrieben, besteht die Klasse View nur aus dem Einlesen und Parsen eines zuvor angelgten Templates. Diese Klasse weiß nicht, ob es sich hierbei um ein Template für eine Aktion handelt oder um ein Layout für die Webseite.

    Im letzten Beitrag hatte ich geäußert eine Klasse Layout anzulegen die unabhängig vom FrontController aufgerufen werden könnte. Im ActionController würde ich nun sofern diese Klasse existiert eine Instanz zur Verfügung stellen mit der ich in der jeweiligen Aktion im (Index)Controller MetaTags oder TitleTag beeinflussen kann. Bevor der FrontController nun seine Response aufliefert wird das Layout eingebunden und ausgegeben.

    seit wann sind Seitentitel und metatags Bestandteil des Layouts ???

    Das sind Bestandteile eines Responseobjekts und auch nur dann wen Du eine html-Seite ausliefern willst, also optional.
    Bei einem Ajax-Request, wie er wahrscheinlich oft vorkommen wird, brauche ich das HTML-Layout garnicht laden, somit wäre dieses eigentlich optional

    Ein kurzes Beispiel, welches in der Kürze der Zeit leider nicht komplett vollständig ist:
    PHP-Code:

      
    // index.php

      
    $layout = &layout::getInstance();
      
    $layout addLayoutDirectory('irgendwas');

      
    $front = &FrontController::getInstance();
      
    $front->addModuleDirectory('irgendwas');
      
    $front->run();

      
    // frontcontroller

      
    public function run() {

        
    // 1. Request verarbeiten

        // 2. Route setzen

        // 3. Controller laden

        // 4. beforeRun() aufrufen

        // 5. Aktion aufrufen

        // 6. afterRun() aufrufen

        // 7. Response aufliefern [Hier ist auch das einzigste Echo() vorhanden]

      
    }

      
    // actioncontroller

      
    public function beforeRun() {

        
    // ist die Klasse layout vorhanden?

        // Instanz dieser Klasse erstellen

      
    }

      public function 
    afterRun() {

        
    // ist die Klasse layout vorhanden?

        // Layout an Response weitergeben

      

    www.webdeveloperfactory.de - Der Blog und Ratgeber für Webentwickler mit zahlreichen Informationen

    Kommentar


    • #47
      Hallo Mano,

      sorry, dass ich erst jetzt antworte, lag aber die letzten Tage im Bett.

      Zunächst freut mich, dass ich durch meine Frage mal wieder leben ins das Thema gebracht habe
      Hatten wir denn bisher kein Leben in der Diskussion?

      Wie schon beschrieben, besteht die Klasse View nur aus dem Einlesen und Parsen eines zuvor angelgten Templates. Diese Klasse weiß nicht, ob es sich hierbei um ein Template für eine Aktion handelt oder um ein Layout für die Webseite.
      Das ist auch nur konsequent. Für die wirklich saubere Trennung sollte sich eine komplette Seite aus mehreren dieser View-Instanzen gemäß dem Composite-Pattern zusammensetzen. Damit wären wir mehr oder weniger wieder bei HMVC bzw. allgemein einem hierarchischen Modell für die Gestaltung der Präsentations-Ebene. Für mich die einzig sinnvolle und konsequente Weiterentwicklung, wenn es um Modularisierung von Anwendungen geht.

      Im letzten Beitrag hatte ich geäußert eine Klasse Layout anzulegen die unabhängig vom FrontController aufgerufen werden könnte. Im ActionController würde ich nun sofern diese Klasse existiert eine Instanz zur Verfügung stellen mit der ich in der jeweiligen Aktion im (Index)Controller MetaTags oder TitleTag beeinflussen kann. Bevor der FrontController nun seine Response aufliefert wird das Layout eingebunden und ausgegeben.
      Kannst du nochmal den expliziten Weg aufzeigen, den der Request jetzt durchläuft. Ich habe das Gefühl, dass wir noch eine zu dichte Abhängigkeit der Komponenten (z.B. Routing, was für ein hierarchisches Modell in den Hintergrund rücken muss) im Spiel haben und damit ein Modul noch nicht sauber gekapselt ist, bzw. es noch nicht möglich ist, mehrere Module parallel zu adressieren. Ebenso muss beachtet werden, dass ein Modul einer Applikation auch Rahmen-Elemente (wie die von dir angesprochenen Meta-Tags/Titel) füllen können muss. Hierzu braucht es ein sauberes Timing-Modell der Request-Abarbeitung (siehe z.B. Timing-Modell des APF-Front-Controller). Das verlinkte Timing-Modell beschreibt beispielsweise explizit, wann eine Action oder ein Filter ausgeführt wird und welche Möglichkeiten des Eingriffs deine Softare hat. Das ist für die Definition eines Moduls und dessen Möglichkeiten zur Initialisierung, Generierung der Ausgabe und Ausführung weiterer Funktionalität von immenser Bedeutung.

      Bei einem Ajax-Request, wie er wahrscheinlich oft vorkommen wird, brauche ich das HTML-Layout garnicht laden, somit wäre dieses eigentlich optional
      Hinsichtlich AJAX oder PDF verhält sich die Ausgabe anderes - korrekt. Wobei AJAX rein technisch betrachtet auch ein XML enthalten kann und damit auch mit den "normalen" View-Komponenten gerendert werden kann. Generiere ich HTML - ein Derivat von XML - ist das auch nichts anderes als XML (selbst). Sofern dein Framework über einen Front-Controller vorsieht, beliebige Actions vor dem Erzeugen der "normalen" View-Komponenten ausführen zu können, kannst du genau das nutzen um den Zustand der Applikation (mit deinen Modulen) zu erzeugen (siehe mein Beispiel) und bist damit im Stande unterschiedlicheste Ausgabe-Formate basierend auf der gleichen technischen Basis auszugeben.

      Ein kurzes Beispiel, welches in der Kürze der Zeit leider nicht komplett vollständig ist:
      Hierzu habe ich folgende Anmerkungen:
      • Die Einführung eines expliziten Layouts halte ich für einen Fehler. Wie bereits angesprochen ist das eine Krücke vieler MVC-Frameworks, denen keine hierarchische Struktur zugrunde liegt, diese über Umwege (Layout, Helper) einzuführen. Diesen Fehler würde ich an deiner Stelle nicht tun und besser from the scratch mit einer hierarchischen Struktur arbeiten. Das erspart Workarounds, erhöht die Wiederverwendbarkeit und führt zu weniger Gefrickel im Code.
      • Das Hinzufügen eines expliziten Modul-Verzeichnisses ist für mich eine unnötige Angabe. Ein Modul sollte über die URL vollständig adressierbar und über evtl. Dritt-Wege (Datenbank, Session, ...) wiederherstellbar sein. In deinem Fall sollte es also möglich sein, mehrere Module in der URL zu codieren und deren Zustand innerhalb von Front-Controller-Actions wiederherzustellen. Alternativ kann hierzu auch ein Input-Filter dienen, der das URL-Layout auflöst und die Action arbeitet auf einem bereits aufgelösten Zustand. Dabei ist zu beachten, dass Module in beliebigen Strukturen deiner Software-Ordner-Struktur vorkommen/auftauchen können. Andernfalls ist der Entwickler an eine (für meinen Geschmack) zu starre Struktur gebunden. Convention over configuration ist zwar inzwischen gerne gesehen, in letzter Zeit verfolge ich jedoch immer wieder Diskussionen, in denen sich Anwender darüber beschweren, dass die Konvention zwar am Anfang hilfreich ist, bei Erweiterungen jedoch in größerem Maß problematisch wird.
      • Das Theme "Route setzen" hatte ich oben bereits angesprochen und halte es in deinem Code-Schema weiter für einen Fehler. Ebenso solltest du dir den Weg nicht durch "Controller laden" verbauen. Auch hier sollte es möglich sein, mehrere Actions und mehrere Controller zu erzeugen und auszuführen. Andernfalls schränkst du dich in der Flexibilität deutlich ein.
      • beforeRun() klingt mir nach Herstellen des Zustands des Moduls. Das ist IMHO eine Aufgabe einer Front-Controller-Action, nicht der Action des Moduls.
      • afterRun() in seiner Funktion des Layout-Handlings ist für mich keine Pflicht einer Action eines Moduls oder gar des Front-Controllers, sondern sollte von einer Komponente abgehandelt werden, die sich auf das Aufbauen und das Management der GUI kümmert. Andernfalls wird der Front-Controller oder die Action des Moduls mit Aufgaben betraut, die sie aus (Software-)Design-Gesichtspunkten nicht haben soll. Ich will mich als Teil einer GUI nicht um den Zusammenbau meiner umliegenden Komponenten kümmern, das muss entkoppelt sein.
      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


      • #48
        lag aber die letzten Tage im Bett.
        Fauler Sack
        [COLOR="#F5F5FF"]--[/COLOR]
        [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
        „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
        [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
        [COLOR="#F5F5FF"]
        --[/COLOR]

        Kommentar


        • #49
          sorry, dass ich erst jetzt antworte, lag aber die letzten Tage im Bett.
          Dann mal gute Besserung

          Die Einführung eines expliziten Layouts halte ich für einen Fehler.
          Wie sollte ich dann mein default.tmpl in der Gesamtstruktur einbinden, sofern ich in der index.php keine Klasse "layout" initialisiere? In meinem Beispiel übergibst Du den Pfad zum Template der Methode start() vom FrontController mit. So etwas könnte ich ich bei mir natürlich auch machen... Und Deine Klasse heißt Page und meine Layout.

          Das Hinzufügen eines expliziten Modul-Verzeichnisses ist für mich eine unnötige Angabe.
          Dieses mag vielleicht sein, aber ich habe dieses in verschiedenen Frameworks gesehen und übernommen, da ich dieses auch sehr gut nutzen kann.

          beforeRun() klingt mir nach Herstellen des Zustands des Moduls.
          Genau, diese beiden Methoden beforeRun() und afterRun() sind optional für den ModulController vorgesehen und können ggf. für das setzen des TitelTags sinnvoll sein um dieses nicht in jeder Action durchführen zu müssen.

          @dr.e. - Ich kann Dir gerne mal Teile von mein bisherigen Code zur Verfügung stellen. Vielleicht wird dadurch einiges deutlicher und Du kannst mir noch gezielter Tipps hierzu geben. Da dieses Projekt leider kein OpenSource wird kann ich dieses hier im Forum nicht veröffentlichen. Wenn dieses möglich ist, dann teil mir doch bitte Deine E-Mail Adresse bzw. ICQ-Nummer mit.
          www.webdeveloperfactory.de - Der Blog und Ratgeber für Webentwickler mit zahlreichen Informationen

          Kommentar


          • #50
            Hallo Mano,

            Dann mal gute Besserung
            Danke, es wird langsam besser...

            Wie sollte ich dann mein default.tmpl in der Gesamtstruktur einbinden, sofern ich in der index.php keine Klasse "layout" initialisiere? In meinem Beispiel übergibst Du den Pfad zum Template der Methode start() vom FrontController mit. So etwas könnte ich ich bei mir natürlich auch machen... Und Deine Klasse heißt Page und meine Layout.
            Der Unterschied zwischen einem Layout und der Klasse "Page" im Beispiel ist doch, dass Page generisch ist, Layout nicht. Hinter Page steckt ein HMVC-Ansatz, hinter den bisherigen Layout-Implementierungen diverser Frameworks habe ich bisher nur einen flachen Ansatz mit sehr begrenzter Komplexität gesehen. Damit beschränkst du dich meiner Meinung nach zu sehr in deinen Freiheitsgraden.
            Richtig siehst du, dass man in irgendeiner Form eine GUI-Struktur initialisieren muss. Das ist aber nicht der Grund, warum ich gegen ein Layout bin, sondern wegen des Inhalts.

            Genau, diese beiden Methoden beforeRun() und afterRun() sind optional für den ModulController vorgesehen und können ggf. für das setzen des TitelTags sinnvoll sein um dieses nicht in jeder Action durchführen zu müssen.
            OK, wenn dein Timing-Modell so arbeitet, ist das legal.

            @dr.e. - Ich kann Dir gerne mal Teile von mein bisherigen Code zur Verfügung stellen. Vielleicht wird dadurch einiges deutlicher und Du kannst mir noch gezielter Tipps hierzu geben. Da dieses Projekt leider kein OpenSource wird kann ich dieses hier im Forum nicht veröffentlichen. Wenn dieses möglich ist, dann teil mir doch bitte Deine E-Mail Adresse bzw. ICQ-Nummer mit.
            Im Moment bin ich ausgebucht - sorry. Sofern es dir nutzt, können wir Mitte/Ende Februar nochmal darüber sprechen.
            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


            • #51
              Richtig siehst du, dass man in irgendeiner Form eine GUI-Struktur initialisieren muss. Das ist aber nicht der Grund, warum ich gegen ein Layout bin, sondern wegen des Inhalts.
              Als Beispiel: Ich hatte gedacht mir eine Klasse, nennen wir sie mal "Layout", für die HTML-Ausgabe zu schreiben. Diese Klasse besitzt beispielsweise die Funktionen setTitle, setMetaTag usw... und bindet mein zuvor abgelegtes Template ein. Über den jeweiligen Controller könnte man nun noch steuern ob dieses wirklich genutzt werden soll. Darüberhinaus könnte man das Layout doch auch noch für die Ausgabe von Ajax auswechseln... oder wie sollte man dieses angehen? Wo und wie sollte ich das Layout einbinden, sodass ich für die Zukunft sehr flexibel bleibe?

              Im Moment bin ich ausgebucht - sorry. Sofern es dir nutzt, können wir Mitte/Ende Februar nochmal darüber sprechen.
              Ich denke, dass ich bis dahin schon etwas weiter bin wie jetzt. Komme aber ggf. gerne darauf zurück.

              Beim Programmieren hat sich bei mir vorhin folgende Frage gestellt:

              Ein Modul kann selbstverständlich aus mehreren Datenbanktabellen bestehen. Bisher habe ich das immer so gehandhabt für die Tabellennamen in einer Konfigurationsdatei Konstanten zu erstellen um diese im Verlauf ändern zu können. Sollte man eine solche Datei die zur Konfiguration der Module genuzt beim Aufruf des ModulControllers einbinden oder schon eher?

              Ähnliches betrifft zukünftig die verschiedenen Sprachen, wie handhabt ihr das?
              www.webdeveloperfactory.de - Der Blog und Ratgeber für Webentwickler mit zahlreichen Informationen

              Kommentar


              • #52
                Hallo Mano,

                Als Beispiel: Ich hatte gedacht mir eine Klasse, nennen wir sie mal "Layout", für die HTML-Ausgabe zu schreiben. Diese Klasse besitzt beispielsweise die Funktionen setTitle, setMetaTag usw... und bindet mein zuvor abgelegtes Template ein. Über den jeweiligen Controller könnte man nun noch steuern ob dieses wirklich genutzt werden soll. Darüberhinaus könnte man das Layout doch auch noch für die Ausgabe von Ajax auswechseln... oder wie sollte man dieses angehen? Wo und wie sollte ich das Layout einbinden, sodass ich für die Zukunft sehr flexibel bleibe?
                Das Geheimnis ist hier das Composite Pattern und eine hierarchische MVC-Umsetzung, die nicht Anwendungs-bezogen sondern generisch abgefasst wird. Das bedeutet, dass jeder Knoten einer Baum-Struktur nun der Root-Knoten sein kann oder auch nicht. Sofern du das jetzt schon konkret abfasst und einen Knoten als explizit gekennzeichneten Root-Knoten (Haupt-Knoten des Layouts) ausführst wird das zukünftig nicht flexibel genug sein.

                Wenn du mein Code-Beispiel mal rekapitulierst, sind alle Elemente "einfach nur" ein Document im Baum, den der Page-Controller verwaltet. Nicht mehr und nicht weniger. Würde ich einen Knoten als Layout-Knoten abfassen hätte ich nicht die Flexibilität beliebig komplexe Strukturen aufzubauen, da ich beispielsweise immer einen Bezug von Knoten zu Layout brauche (z.B. Linker Bereich im Layout). Setzte ich das generisch um (im Beispiel durch ein View-Model abstrahiert), so kann alles das Layout einer weiteren Verästelung des Baumes sein oder eben nicht.

                Ein Modul kann selbstverständlich aus mehreren Datenbanktabellen bestehen. Bisher habe ich das immer so gehandhabt für die Tabellennamen in einer Konfigurationsdatei Konstanten zu erstellen um diese im Verlauf ändern zu können.
                Warum nutzt du nicht verschiedene Datenbanken für die verschiedenen Module? So kommen sich diese hinsichtlich der Benamung nicht in die Quere. Präfixe sind doch "nur" ein Workaround für "nicht genug Datenbanken beim Hoster verfügbar".

                Sollte man eine solche Datei die zur Konfiguration der Module genutzt beim Aufruf des ModulControllers einbinden oder schon eher?
                Das kommt auf den Anwendungsfall an. Die Tabellen, die zur Konfiguration der Module und zur Ausführung der FC-relevanten Komponenten angeht muss das ja schon vor dem Controller/der Action des Moduls passieren. Wobei "einbinden" hier das Auslesen und interpretieren der Informationen zur Ausführung des Modules/der Module bedeutet.

                Ähnliches betrifft zukünftig die verschiedenen Sprachen, wie handhabt ihr das?
                Die Sprache sollte eine Modell-Information sein, die jedem Baum-Knoten und jedem Service zur Verfügung steht. Damit schaffst du eine Basis um auf jedem Knoten/Element die Sprache als Information zu nutzen oder diese gemäß den Vorgaben der Applikations-Logik zu manipulieren.
                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


                • #53
                  Wenn du mein Code-Beispiel mal rekapitulierst, sind alle Elemente "einfach nur" ein Document im Baum, den der Page-Controller verwaltet. Nicht mehr und nicht weniger. Würde ich einen Knoten als Layout-Knoten abfassen hätte ich nicht die Flexibilität beliebig komplexe Strukturen aufzubauen, da ich beispielsweise immer einen Bezug von Knoten zu Layout brauche (z.B. Linker Bereich im Layout). Setzte ich das generisch um (im Beispiel durch ein View-Model abstrahiert), so kann alles das Layout einer weiteren Verästelung des Baumes sein oder eben nicht.
                  Ich denke, dass es momentan noch absolut nicht bis ins kleinste Detail flexibel sein muss. Dieses wäre zwar super schön, aber derzeit mehr als unbedingt zwingend notwendig. Ich werde mir zu diesem Punkt noch einige Beispiele anschauen und hierzu eine Maßgeschneiderte Lösung für meinen Anwendungsfall entwerfen. Das was ich hier unter Beachtung eines MCV umsetzen möchte, ist schon etwas überdimensioniert Das könnte mir ein Kunde schon garnicht bezahlen... sooo viele Arbeitsstunden...

                  Warum nutzt du nicht verschiedene Datenbanken für die verschiedenen Module? So kommen sich diese hinsichtlich der Benamung nicht in die Quere. Präfixe sind doch "nur" ein Workaround für "nicht genug Datenbanken beim Hoster verfügbar".
                  Von meinem Server hat sollte das keine Probleme geben, den soviele Datenbanken wie ich anlegen könnte, würde ich im Leben nicht nutzen können. Ich bleibe definitiv bei einer Datenbank

                  Das kommt auf den Anwendungsfall an. Die Tabellen, die zur Konfiguration der Module und zur Ausführung der FC-relevanten Komponenten angeht muss das ja schon vor dem Controller/der Action des Moduls passieren.
                  Also müsste dieses schon während der Dispatch im FrontController stadtfinden?
                  www.webdeveloperfactory.de - Der Blog und Ratgeber für Webentwickler mit zahlreichen Informationen

                  Kommentar


                  • #54
                    Das könnte mir ein Kunde schon garnicht bezahlen... sooo viele Arbeitsstunden...
                    Das muss ich jetzt nicht kommentieren, oder? (Wer wollte keine fertige und erprobte Lösung einsetzen? ) An sich hatte ich dir mit meinem Beispiel schon 10 Tage Diskussion hier erspart, aber gut.

                    Also müsste dieses schon während der Dispatch im FrontController stattfinden?
                    Nein, der Front-Controller sollte transparent sein. Dein Applikations-eigener "Dispatch-Vorgang" muss in einer Action passieren, die beim FC registriert ist. Nur dann kannst du den FC auch für andere Projekte nutzen.
                    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


                    • #55
                      Das muss ich jetzt nicht kommentieren, oder?
                      Wenn man es genau nimmt, könnte ich auch eine beliebige Software zur Vereinsverwaltung nehmen die auf dem Markt existiert. Dadurch wäre die gesamte Programmierung überflüssig und der Lerneffekt gleich null

                      Für mich ist dieses ein Projekt, welches es mir ohne eine genaue Zeitvorgabe erlaubt meine eigenen Ideen und Vorstellungen so umzusetzen wie ich das gerne hätte. Da ich eine solche Freiheit in unserer Agentur nicht habe, bin ich über die Entwicklung hier sehr froh

                      Wie gesagt, ich bin wirklich dankbar über eure Tipps und melde mich während der Zeit bestimmt nochmal
                      www.webdeveloperfactory.de - Der Blog und Ratgeber für Webentwickler mit zahlreichen Informationen

                      Kommentar


                      • #56
                        Hallo,
                        ich bin mit meiner Entwicklung nun noch einen weiteren Schritt in dieser Woche voran gekommen und habe heute begonnen meine bisherige Session-Klasse zu überarbeiten. Ich hatte mir übrelegt, die neue Session-Klasse weiterhin als Singleton-Instanz aufrufbar zu machen, da ich nicht jede Methode neu als Static deklarieren möchte.

                        Im bisherigen Projekt nutzte ich bereits eine Klasse für die Authentifikation der Benutzer. Diese enthält allerdings noch die Funktionen für "user_login(user, pw)" und "user_logout" die in dem neuen Schema jedoch überflüssig werden, da diese Methoden im Login-Modul im entsprechenden Model genutzt werden können.

                        Bei zwei Funktionen bin ich mir allerdings nicht nicht sicher:

                        1) Bisher wird bei jedem Seitenaufruf eine Funktion der User-Klasse aufgrufen die eine Datenbankabfrage durchführt und aktuelle Informationen in der Benutzertabelle speichert. Sollte ich dieses weiterhin hier belassen oder auslagern, wenn ja wohin?

                        2) Außerdem war in der bisherigen Klasse eine Funktion integriert die nach dem Login ein komplexe Logik an Benutzerrechten zusammenbaut und diese in einem Session-Array speichert. Grundsätzliche könnte ich diese Funktion auch im Login-Modul unterbringen. Mich würde allerdings interessieren, wie ihr in solchen Fällen damit umgeht?
                        www.webdeveloperfactory.de - Der Blog und Ratgeber für Webentwickler mit zahlreichen Informationen

                        Kommentar


                        • #57
                          1) Bisher wird bei jedem Seitenaufruf eine Funktion der User-Klasse aufgrufen die eine Datenbankabfrage durchführt und aktuelle Informationen in der Benutzertabelle speichert. Sollte ich dieses weiterhin hier belassen oder auslagern, wenn ja wohin?
                          FC-Action des Login-Moduls. Das ist eine globale Angelegenheit, die per Facade oder Proxy für alle Module zugreifbar sein sollte.

                          2) Außerdem war in der bisherigen Klasse eine Funktion integriert die nach dem Login ein komplexe Logik an Benutzerrechten zusammenbaut und diese in einem Session-Array speichert. Grundsätzliche könnte ich diese Funktion auch im Login-Modul unterbringen. Mich würde allerdings interessieren, wie ihr in solchen Fällen damit umgeht?
                          Berechtigungen sind eine Eigenschaft des Benutzers. Ich sollte - wie oben angedeutet - in einem beliebigen anderen Modul sowas wie

                          PHP-Code:
                          $perms $user->getPermissions() 
                          aufrufen können. Dabei sollte der User als zentrales Model verfügbar sein (z.B. als UserFacade, die du singleton beziehen kannst).
                          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


                          • #58
                            Soweit so gut. Würdest Du grundsätzlich Rechte für Benutzer nicht direkt in einer Session speichern? Dann würde ich mir ggf. eine Funktion in der User-Klasse sparen ....
                            www.webdeveloperfactory.de - Der Blog und Ratgeber für Webentwickler mit zahlreichen Informationen

                            Kommentar


                            • #59
                              Nein, denn direkt in der Session ist hinsichtlich der Kapselung unsauber.
                              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


                              • #60
                                Hallo,

                                auch ich möchte mal meinen aktuellen Stand mitteilen. Mein MVC-Framework nimmt immer mehr Formen, sodass ich bald die ersten Module dafür entwicklen möchte. Vorab bin ich allerdings dabei sog. Programmierrichtlinien kurz schriftlich zu fixieren.

                                Innerhalb eines Modul-Ordners gibt es drei Unterordner.

                                1. models

                                Klassenbennung: class test { }
                                Dateibennnung: class.test.php

                                2. views

                                Dateibennung: action.phtml

                                3. controllers

                                Klassenbennung: indexController (nur was ist wenn ich pro Modul einen habe? event_indexController ?!)
                                Dateibennung: controller.KLASSE.php

                                Oder habt ihr eine andere Idee für die Namenskonventionen?
                                www.webdeveloperfactory.de - Der Blog und Ratgeber für Webentwickler mit zahlreichen Informationen

                                Kommentar

                                Lädt...
                                X