Hallo frankx,

Suche ich mir die aus dem Framework zusammen, oder?

Ich meinte eher, wie gliedere ich die Anwendung in Komponenten, die ich dann selbst schreiben muss.

MVC, anhand der vom Framework vorgeschlagenen Konventionen.

MVC kümmert sich nur um zwei Ebenen, gut bei Webanwendungen ist die dritte meist die Datenbank. Außerdem sind Webanwendungen oft sehr monolitisch.

Nehme ich für /artist , /location , /agency je drei verschiedene controller, wie beim Standardrouting des ZF vorgesehen, oder route ich zu einem Controller und einer View, die wiederum mit Datensätzen aus den zugrundeliegenden Tabellen gefüttert werden.

Du erwähnst gar kein Datenmodell, anscheinend ist das Modell mit der Datenbank für Dich identisch. Bei sehr Datenbank-zentrierten Anwendungen ist das oft so. Es kann aber auch sein, dass Du ein Objektmodell hast, das von der ganzen Awendung verwendet wird, und weitere Objektmodelle, die von anderen funktionalen Komponenten (z.B. deinem /artist /location /agency) eingeklingt werden. Dieses Objektmodell muss dann wiederum in die Datenbank gespeichert werden können und das will man natürlich auch nicht zentral erledigen, sondern separat für jedes Teilmodell.

Das wäre dann wohl das o.g.

Ja, es ist eine Lösung für typische Webanwendungen. Gerade für datenbankbasierte Webanwednungen gibt es da sehr viel.

Das kapier ich scheints nicht. Eine Abstraktionseben höher noch wohl, einen Baukasten für Baukästen? Ein Meta-Framework?

Nein, Entwurfsmuster sind ja auch kein Framework, auch MVC ist kein Framework. Ich meinte eher eine Theorie, eine Herangehensweise. Vor allem eine, die nicht nur für Webanwednungen taugt. Das Thema Webanwendungen wird mit Frameworks und Standardarchitekturen ja geradezu zugeschüttet.

Die Kombination von Front-Controller als Singleton mit MVC scheint mir recht funktional.

Nur Singelton ist davon ein Entwurfsmuster und wahrscheinlich noch das fragwürdigste. Es wird nicht grundlos oft als die globale Variable der Objektorientierung bezeichnet ;-)

Viele Webanwedungen sind meiner Meinung nach sowieso nicht so sehr objektorientiert. Das liegt daran, dass eine Webanwendung oft nur Eingaben entgegen nimmt, mit der Datenbank kommuniziert und Daten wieder ausgibt.
Diese "Daten-rein-Daten-raus"-Architektur macht die Sache erstmal sehr einfach. Desktopanwendungen, wo wirklich ein objektorientiertes Datenmodell über die gesammte Anwendungslaufzeit existiert, sind da komplexer.
Die Komplexität der Webanwendungen steckt dann oft in irgend welchen SQL-Queries, die über die Anwedung verteilt sind. Das führt dann natürlich dazu, dass Information über die Struktur der Datenbank wild über die Anwendung verteilt ist. Mit Objektorientierung löst man das Problem allerdings auch nicht.

Grüße

Daniel