[kampfgnom]

mhmm, also das hab ich ganz ehrlich nicht verstanden.
Also:
als erstes der Frontcontroller dann -und hier kommt das was ich nicht verstehe- der Controller.
Hä? was macht der dann?
Ich hab mir gedacht, das ich das ganze dem Model gebe und das die Daten holt...oder sollte ich das Model lieber Controller nennen?!

Aber was macht dann das model?


P.S.: Ich hatte gerade 8h JugendRedeForum....kann auch daran liegen. Wäre trzd dankbar wenn ihr mir das erklären könntet!

[$traight-$hoota]

Also ein Ablauf könnte ungefähr folgendermasen aussehen (anhand eines kleinen Beispiels skizziert

1. URL wird aufgerufen: /news/1,hello world
2. Server startet Skript, Frontcontroller wird initialisiert
3. Frontcontroller lädt Config, etabliert Datenbankanbindung etc.
4. Frontcontroller analysiert Query
   • modul: news
   • controller: view_item
   • params: id=1;title=hello world
5. Frontcontroller lädt Modul "news" und ruft Controller "view"
6. Controller "view_item" erstellt ein News-Model für id=1
7. Controller "view_item" prüft den Request beispielsweise auf Zugriffsberechigung und Existenz des Eintrags
8. Controller "view_item" übergibt Model und Renderpfad ("Templatedatei") an View (Template-engine)
9. Frontcontroller leitet das Rendering der View ein und überträgt die Ausgabe an den Client

Der Controller ist also quasi dafür da, zu sagen, was genau geschehen soll, wenn ein bestimmte request eingeht. In obigem Fall also, dass das Model für einen News-Eintrag gesucht werden soll, danach beispilsweise überprüft, ob das Model korrekt erstellt wurde und der gegenwärtige User Zugriff darauf hat. Danach sagt er der View, was diese darstellen soll (nämlich das erstellte Model, mit dem News-text) und wie (nämlich z.B. durch die datei "/template/news_item.tpl").

[kampfgnom]

achso, ok das hab ich verstanden!! danke!!!

[dr.e.]

5. Frontcontroller lädt Modul "news" und ruft Controller "view"

Ich würde hier eine weitere Abstraktion einbauen, da eine Webseite oft mehrer Module enthält und diese oft Abhängigkeiten haben.

[$traight-$hoota]

Zitat von dr.e.

Ich würde hier eine weitere Abstraktion einbauen, da eine Webseite oft mehrer Module enthält und diese oft Abhängigkeiten haben.

Ja, klar, das ganze ist nur eine gekürzte Übersicht. Für ne echte Implementierung fehlen natürlich noch dutzende Sachen...

[Basti]

Hi.

Zum konkreten Entwurf bzw. den Kommentaren hier noch eine Anmerkung von mir zum Thema Module:

Als ich angefangen habe, ein auf MVC aufbauendes CMS zu schreiben hab ich den Fehler gemacht, jedem Modul eine Modell-Klasse beizupacken. Ich hab erst später kapiert, dass sich Modell-Klassen nicht 1:1 in Module stopfen lassen und welche Funktionen sinnvollerweise in die Modell-Schicht gehören und welche in die Controller müssen.

Letztlich ist es aber immer eine Frage, was du brauchst, wobei wir wieder beim eigentlichen Thema wären, wie man an so eine Aufgabe rangeht.

Bei der Entwicklung eines Frameworks muss der Fokus - wie bei allen anderen Anwendungen auch - auf den Bedürfnissen der Zielgruppe liegen. In dem Fall sind das also Programmierer und die Seitenbetreiber. Es geht darum, dass die Programmierer die Wünsche der Seitenbetreiber möglichst flott umsetzen können. Und hier gilt es einen Weg zu finden zwischen Einschränkung der Möglichkeiten auf der einen Seite und der Breite an Anforderungen auf der anderen Seite.

Und das ist letztlich das Thema, das unsere Arbeit täglich bestimmt. Zum Beispiel bei der Erstellung einer Benutzeroberfläche. Gib dem Benutzer 3 Optionen und er wird leicht verstehen, was er da machen kann, wird seine 3 Hauptaufgaben in einer optimalen Geschwindigkeit erledigen können.

Aber, er kann dann eben auch nur diese drei Dinger machen. Genauso beim Software-Entwurf. Pack deine Funktionen und Daten in kleine abgeschlossene Häppchen, in Klassen und Module und du wirst (hoffentlich) sehr einfach damit arbeiten können. Aber, du hast so natürlich auch nur die Möglichkeiten, die die jeweils zur Verfügung gestellten Schnittstellen bieten.

Es gibt da z.B. PHP-Software, in der mitten zwischen der HTML-Ausgabe Datenbankabfragen gemacht werden etc. Wenn du da was an der Datenbankstruktur ändern möchtest, an der Fehlerhandhabung oder gar das ganze DBMS auswechseln willst, dann hast du ein riesiges Problem (oder auch einen dicken Auftrag, der dich ein paar Wochen ernährt - wie man`s minnt). Willst du aber eine Kleinigkeit ändern, dann ist das mitunter in wenigen Handgriffen einfach erledigt, ohne dich erst in die Konzepte einarbeiten zu müssen, ohne irgendwelche in Code gegossenen Konventionen einhalten zu müssen oder ggf. sogar gewaltsam aufbrechen zu müssen.

Du machst also nichts anderes, als die Fülle der Möglichkeiten zu Gunsten einer leichten Bedienung (durch den Programmierer genauso, wie durch den Benutzer später) künstlich zu beschränken, in bestimmte Kanäle zu lenken etc.

Das ist, wie wenn du eine virtuelle Firma aufbaust. Wenn da jeder alles können soll, dann bist du unglaublich flexibel, hast aber sehr schnell Kommunikationsprobleme (Weiß jetzt jeder Bescheid? Wer hat diesen Fehler gemacht?). Wenn du nur lauter Fachidioten und starre Strukturen hast, dann läuft der Laden wie geschmiert, kann aber bestimmte Entwicklungen so nicht mitmachen.

Und hier hilft dann letztlich nur die Erfahrung, Widersprüche im Entwurf und Sackgassen frühzeitig zu erkennen. Oder anders gesagt: Du musst das Problem in deiner Birne in seiner ganzen Komplexität erfassen und bis in die letzten Winkel durchdenken, immer wieder aus anderen Winkeln anschauen, zerlegen und neu zusammensetzen, Entscheidungen treffen und Opfer erbringen, bis du eben dieses Verständnis des Problems in Form von Code in den Rechner hackst.

Und als Verlängerung deiner Synapsen kannst du eben Modelle hernehmen, kannst das Problem oder Lösungsansätze visualisieren. Das ist natürlich viel aufwändiger, als alles im Kopf zu haben, aber ab einer gewissen Komplexität (keine Ahnung, wie viel du davon vertragen kannst) ist das einfach notwendig, um voranzukommen. Mir hilft es auch, einen Dialog zwischen dem Problem und möglichen Lösungsansätzen aufzuschreiben. Einfach einen Text-Editor aufmachen und meine Gedanken runterschreiben. Oft liegen die Lösungen schon in der Ausformulierung des Problems oder ergibt sich aus der Auflistung der Lösungs-Optionen, welcher Weg welche Opfer erfordert.

Ich glaube, es ist einfach wichtig, hier in einen inneren Dialog einzusteigen. Genauso, wie du immer einen Cracker in dir brauchst, der ständig nach der Sicherheitslücke sucht, brauchst du einen Kritiker in dir, der ständig nach der Grenze, nach dem Widerspruch, nach dem Fehler in deinem Entwurf sucht. Wenn du den nicht im Vorfeld konsultierst, dann wird er dir Wochen später von deinem Monitor aus entgegengrinsen und dir tagelange Umbauarbeiten bescheren.

Die meiste Software ist zu komplex, um nicht doch immer wieder von den eigenen Fehlern überrascht zu werden, aber mit der Erfahrung wächst eben auch die Achtsamkeit und die Sehschärfe.

Für mich ist das der ganze Reiz, der diese Arbeit so spannend macht. Es geht nicht darum, tote Ziffern in die Rechner zu hacken, sondern Probleme zu lösen. Und das heißt eben, sie zu verstehen, genau hinzuschauen, noch genauer hinzuschauen, nochmal anders hinzuschauen und dann eben immer wieder Entscheidungen zu treffen, Bauernopfer zu bringen, aber auch mal einfach ausprobieren, wie weit man mit einem Ansatz kommt, wie sich einer von den vielen möglichen Wegen in der Praxis anfühlt.

Basti

[mepeisen]

Genau wegen dieser aufkommenden Diskussion habe ich gezielt nach Anwendungsbeispielen bzw. Praxisbeispielen gefragt. Dann zeigt sich, wo man Verbesserungen vornehmen muss, wo etwas noch nicht klar definiert ist.

Wie Basti schrieb, muss man immer ein Ziel verfolgen und gerade bei Frameworks muss man sich eigentlich immer an Referenzbeispielen orientieren und beiher in der Theorie und auch später in der Praxis diese Beispiele ausformulieren. Das soll nichts komplexes von der Logik her sein. Beispielsweise ein einfaches Gästebuch ohne großartigem BB-Code Schnickschnack oder sowas.

Wie man das mit den FrontControllern löst, ist letzlich Geschmacksache. Das Zend Framework geht den Weg das, was du hier als FrontController verstehst, zu kapseln und ein Entwickler bietet dann dem Zend-Framework einen "ArbeitsController", der die tatsächliche Arbeit erledigt. Dabei gibt die URL genaue Informationen darüber, welchen Controller das Zend-Framework aufrufen soll und welche Methode. Aber selbst wenn du sowas in einen "FronController" vereinst, also sowohl das Parsen der URL, als auch die Facharbeit, musst du immer noch irgendwie eine Verbindung zustande bringen zwischen deiner URL und dem, was du hintennach tun willst. Dein Framework weiss nichts von einem Gästebuch und weiss daher auch wenig darüber, was es mit einer URL anfangen soll.

Zum MVC noch ein Wort:
Klar kann das alles manchmal verschwimmen. Aber klassischerweise ist das wie folgt eingeteilt:

- Model enthält die unterste Ebene des Datenmodells einer Anwendung. Man geht bei der Modell-Entwicklung ähnlich vor, wie bei der Datenbank-Entwicklung. Beispielsweise gibt es die Modell-Klasse "Auto" und dort die Methode "gibFarbe". Das wars prinzipiell schon. Zusätzlich dazu enthält das Modell sogenannte Business-Logik. Hier wirds schwammig, da oft genug Entwickler unterschiedliche Ansichten haben, was alles Business Logik ist bzw. wie weit das geht. Aber beispielsweise kann das Auto die Methode "verkaufe(Person)" enthalten, um ein Auto an eine Person zu verkaufen. Was dann im Hintergrund passiert, dass es sich um einen gewerblichen Verkauf handeln kann, wenn es beispielsweise einem Autohändler gehört, oder um einen privaten Verkauf, das ist Bestandteil der Business-Logik. Was streng genommen NIE Bestandteil der Business-Logik bzw. des Modells sein darf, ist die Oberflächenpräsentation (z.B. Methode maleJpeg) oder die Verbindung zur Oberfläche (z.B. das Ausgeben des Hinweises "Auto wurde erfolgreich verkauft!"). Idealerweise kann das Modell auch als Teil der Business-Logik die SQLs abbilden, die zum Auslesen/ Verändern eines Objektes gebraucht werden. So ist das gut und zentral gekapselt.

- View enthält die Oberflächenpräsentation, beispielsweise das Anzeigen des Autos mitsamt der technischen Daten und einem Bildchen. Sie basiert auf dem Modell bzw. liest es aus. Sie bietet Schnittstellen an, mit denen ein Benutzer interagieren kann, also bei Webseiten Bupperls, Formulare und Links.

- Controller ist einfach, denn das ist der gesamte Rest . Es schafft die Verbindung zwischen View und Modell bzw. sagt der View, was sie denn anzeigen soll. Es füllt die Benutzerinteraktionen mit leben, validiert die Eingaben und gibt eventuelle Fehlermeldungen aus bzw. generiert sie; Alternativ wirft das Modell beim Verkaufen eine Exception mit Info "Das Auto darf man nicht an sich selbst verkaufen!". Der Controller kann auf mehrere Modell-Objekte in einem Request zugreifen, beispielsweise als erstes auf das Modell-Objekt "Berechtigung", um zu prüfen, ob der User überhaupt das Auto verkaufen darf. Dann erst greift es auf das Objekt "Auto" zu.

[kampfgnom]

Also an euch beiden und an alle anderen die mir hier versuchen zu Helfen erstmal ein riesen großes DANKESCHÖN!

Ich glaube solangsam zu verstehen und entdecke auch schon meinen ersten Fehler:
Ich hab versucht das ganze sozusagen universell zu lösen, also ohne konkrete Anwendung, im nachhinein natürlich völliger Schwachsinn

Aber jetzt werd ich erstmal eure beiden sehr ausführlichen Beiträge Verdauen und mich dann nochmal melden!

Aber es ist echt der Hammer wieviel Zeit ihr euch für sowas nehmt!!
DANKE!

[Basti]

Kleine Ergänzung:

In PHP-Anwendungen lässt man in der Regel nicht die Views die Daten aus der Modell-Schicht ziehen, sondern lässt das die Controller machen (die haben die Daten ja in der Regel eh schon in der Hand). Die Controller greifen also auf die Daten zu und übergeben diese den Views:

PHP-Code:

<?php

class BookStore extends Controller
{
    public function displayBook()
    {
        $iBookId = $this->Request->get('book', TYPE_INT, null);
        $Book    = Book::get($iBookId);

        if ($Book) {

            $View = new View('book.display');
            $View->assign('book', $Book);

        } else {

            $View = new View('book.notExists');
        }
        return $View;
    }
}

Oder die Werte werden dadurch den Views zugänglich gemacht, indem diese in den Controllern als öffentliche Variablen zugewiesen werden (siehe z.B. Symfony).

Über die einzelnen MVC-Ausprägungen und -Varianten (Model 2, HMVC oder auch rekursives MVC, aktives, passives Modell etc.) gibt es aber bereits derart viele Abhandlungen im Netz, dass wir uns das hier sparen können. Wollte nur den Hinweis einbringen, dass es eben viele Varianten gibt und dass das MVC in der PHP-Welt in der Regel wenig mit dem klassischen Pattern zu tun hat.

Sichtbar wird hier aber vielleicht, dass es sehr sinnig ist, sich mit offenen Augen umzuschauen und zu lernen, wie andere Entwickler ähnliche Probleme gelöst haben. Oft lassen sich Ideen und Konzepte auch aus ganz anderen Bereichen übertragen. Noch öfter aber findet man selbst eine geniale Lösung, nur um dann festzustellen, dass genau diesen Weg schon viele Entwickler vor einem gegangen sind. Aber - ich denke, es ist trotzdem gut, diese Erfahrung zu machen, denn ein Problem selbst zu lösen gibt einem natürlich ein ganz anderes Verständnis, als die fertige Lösung. Dauert aber auch länger und das Ergebnis kommt dann an die etablierten und praxiserprobten Lösungen oft doch nicht heran.

Basti

PS:
Ja, es gibt keine universelle Lösung für alles. Ich denke, in jedem Entwicklungsprozess kommt man immer wieder an diesen Punkt, an dem keine der möglichen Lösungen perfekt ist und man eben einfach eine Entscheidung treffen muss. Jede Design-Entscheidung hat Vor- und Nachteile und ohne klares Ziel vor Augen hat man dann keinen Maßstab anhand dessen man die Prioritäten setzen kann. Auch braucht es eben ein "höheres" Ziel, für das man die Nachteile einer Entscheidung in Kauf zu nehmen bereit ist. Diese Punkte sind wie dazu geschaffen aufzugeben, innerlich auszusteigen. Mit klarem Ziel vor Augen macht man halt einen Tag Urlaub und geht dann nochmal rein und schmeißt dann eben mal wieder ein Stück einer Vorstellung von der perfekten und durchweg ästhetischen Lösung über Bord. Ohne Ziel wirst du aber wahrscheinlich eher das ganze Projekt weglegen, als es zuende zu bringen, als in Stein gemeißelten Beweis dafür, dass du ein Problem nicht vollständig lösen konntest. (Mein Gott, wie poetisch )

[kampfgnom]

Ok, hab mir nomma was überlegt:
http://aedo.ae.ohost.de/bg-f_request2.gif
(hab jetzt mal die Error-Pfeile rausgelassen, wurde unübersichtlich)
Und zwar hab ich mir folgendes gedacht:
Der FrontController ruft je nach Pattern ein bestimmten Controller auf.
Der wiederum weiß welches Model er zu benutzen hat.
Das holt sich dann die Daten aus der DB oder sonst wo her.
Der Controller verarbeitet das ganze für den View, der gibt es aus.

Ich glaub jetzt hab cih das ZF im Ansatz kopiert oder?!

So jetzt gebt mal euren Senf ab^^

[robo47]

Der Pfeil zwischen FrontController und Model besteht eigentlich nicht, sondern der sollte vom Controller zum Model gehen

[$traight-$hoota]

Zitat von robo47

Der Pfeil zwischen FrontController und Model besteht eigentlich nicht, sondern der sollte vom Controller zum Model gehen

Jo, denn der Frontcontroller wählt aus, welcher Controller aufgerufen wird.

[dr.e.]

Der Diskussion sollte noch hinzugefügt werden, dass es zwei Formen von "Model" gibt. Zum einen speichert ein Model (=Daten-Objekt) Informationen, die persistiert worden sind, zum anderen kann ein Model (=Zustand einer Applikation) aber auch Laufzeit-Informationen bereitstellen. Zum Thema CMS hat Basti ja bereits bemerkt, dass nicht unbedingt jedes Modul sein eigenes Model haben muss. Dezentralisiert man das weiter, so ist es sogar sinnvoll der Basis eines CMS eine zentrale Business-Komponente mitzugeben, auf die man im Controller zugreifen und diese verwenden kann. Diese kennt dann beispielsweise

- Aktuelle Sprache
- Aktuell gewählter Navigationspunkt
- Anzuzeigende Inhalte
- ...

je weiter man das abstrahiert, um so einfacher wird es später ein Modul einzuklinken, da dieses beispielsweise den aktuellen Navigationsknoten benötigt, oder Informationen wie die Sprache.

[Basti]

Ich würde das in ein Sequenzdiagramm umschreiben.

Weiter würde ich "Config loader" einfach "Config" nennen, denn dieses Objekt repräsentiert ja dann die Konfiguration. Ob es die Daten "lädt" oder schon in sich trägt etc. ist von außen gesehen völlig irrelevant.

Dann würde ich immer gleich alles mit englischen Bezeichnern versehen. Gibt da auch Gegenstimmen, jedoch hat es in meinen Augen Vorteil nur eine sprache zu verwenden und nicht zwei. Und da eben eh schon das meiste in englisch ist (PHP-Funktionsnamen etc.), fällt die Entscheidung eigentlich nicht schwer.

Bei "Errorclass" wäre meine Frage, was genau das ist und ob das vielleicht nicht auch in das Schema der "normalen" Abläufe reinpasst, also ein Controller, der entscheidet, ob der Fehler angezeigt und/oder geloggt oder an den Administrator gemailt werden soll. Ein Error-Objekt, das die Infos enthält (wo ist welcher Fehler aufgetreten und wie) und ggf. eine Asgabe über dein Template-System.

Ist natürlich wieder die Frage, was du willst. Je komplexer eine Fehlerbehandlung, umso fehleranfälliger ist sie natürlich selbst.

Basti

[kampfgnom]

Zitat von Basti

Ich würde das in ein Sequenzdiagramm umschreiben.

Weiter würde ich "Config loader" einfach "Config" nennen, denn dieses Objekt repräsentiert ja dann die Konfiguration. Ob es die Daten "lädt" oder schon in sich trägt etc. ist von außen gesehen völlig irrelevant.

Dann würde ich immer gleich alles mit englischen Bezeichnern versehen. Gibt da auch Gegenstimmen, jedoch hat es in meinen Augen Vorteil nur eine sprache zu verwenden und nicht zwei. Und da eben eh schon das meiste in englisch ist (PHP-Funktionsnamen etc.), fällt die Entscheidung eigentlich nicht schwer.

Bei "Errorclass" wäre meine Frage, was genau das ist und ob das vielleicht nicht auch in das Schema der "normalen" Abläufe reinpasst, also ein Controller, der entscheidet, ob der Fehler angezeigt und/oder geloggt oder an den Administrator gemailt werden soll. Ein Error-Objekt, das die Infos enthält (wo ist welcher Fehler aufgetreten und wie) und ggf. eine Asgabe über dein Template-System.

Ist natürlich wieder die Frage, was du willst. Je komplexer eine Fehlerbehandlung, umso fehleranfälliger ist sie natürlich selbst.

Basti

Ok das mit den Englischen namen leuchtet ein

Zur Frage wegen der Errorclass. Naja ich dachte mir, dass jede Classe ihre Fehler an diese Klasse weitergibt. Exceptions etc. und dann wird das ganze geloggt ausgegeben was auch immer.
Beim schreiben ist mir aber gerade eine Frage eingefallen.
Wie setzt man am besten um, was mit dem Error passiert?
Sollte man das evtl über methoden machen?! Da hab ich noch keine Idee

[Basti]

Zitat von kampfgnom

Wie setzt man am besten um, was mit dem Error passiert?

Was passiert denn mit dem Error?

Basti

[mepeisen]

Noch ein Wort dazu:

Zitat von Basti

In PHP-Anwendungen lässt man in der Regel nicht die Views die Daten aus der Modell-Schicht ziehen, sondern lässt das die Controller machen (die haben die Daten ja in der Regel eh schon in der Hand). Die Controller greifen also auf die Daten zu und übergeben diese den Views:

Also das hat nichts mit originär mit PHP zu tun. Ansonsten ist es eine Philosophiefrage. Es gibt Stimmen, die bevorzugen, dass das Model weiss, dass es ein Auto vor sich hat und genau weiss, wo es die Farbe her bekommt. Die View weiß also um ein getAuto und ein getFarbe.
Dann gibt es wieder die Chance, dass der Controller eigenständig das Model so aufbereitet (als Array o.ä.), dass die View gar nichts vom Model kennt. Beispielsweise werden Farbvariablen in Templates der View definiert, die vom Controller gefüllt werden müssen. Smarty ist ein gutes Beispiel. Auch wenn Smarty mehrere Pattern gleichzeitig beherrscht.
Die Dritte Variante ist, dass der Controller auf abstrakter Basis der View mitteilt, woher die relevanten Informationen stammen. Die View muss also eine Farbe XYZ füllen. Der Controller teilt der View mit: Aus dem Modell kommt die Farbe über "getAuto -> getFarbe". Das wäre eine Art Mischmasch. Man spricht danhn auch oft von ModelBinding bzw. allgemein von Binding.

Wie gesagt hat das nix mit PHP als solches zu tun. Die drei Varianten sind in allen Sprachen möglich.
Klar gibt es Wildwuchs.

[kampfgnom]

Naja der Error, wird an die Klasse weitergegeben (Wie weiß ich ja noch nicht )
Dann kann entschieden werden ob der Fehler für den View aufgearbeitet wird, ob er gelogged werden soll, ob der Admin ne mail erhalten soll.
Oder eben ne Kombination davon.
Man könnte jetzt für verschiedene Error Nummern Regeln definieren....

[Basti]

Zitat von mepeisen

Also das hat nichts mit originär mit PHP zu tun.

Das war auch nicht meine Aussage. Ich kenne mich in den Welten anderer Sprachen nur nicht wirklich aus und in PHP-Software wird das eben in praktisch allen Fällen so umgesetzt. Dass sich die Views die Daten direkt aus dem Modell ziehen ist die Ausnahme.

Basti

[kampfgnom]

So war heute in Dresden "Shoppen" hatte von meinem Geburtstag noch einen Geschenk Gutschein bei Buch und Kunst.

Also reingegangen und mir ist gleich erstmal die PHP Abteillung aufgefallen.

Ich hab mir jetzt das Buch:
PHP Design Patterns von Stephan Schmidt aus dem O'REILLY Verlag gekauft.

Sah ganz Interresant aus. Da wird auch mal das Thema UML Angeschnitten.
Das ist ja mein Aktuelles Problem...