Hallo frankx,

Auf _einem_ Kern aufbauend? Dem Front-Controller?

Vielleicht, aber eher der Datenbank.
Stellen wir uns mal eine Webanwendung aus mehreren Komponenten vor. Forum, CMS, vielleicht ein Wiki, eine Suche, ...
Es gibt natürlich irgendwie eine Benutzerverwaltung, die mit vielen dieser Komponenten verknüpft ist. CMS und Wiki sind ähnlich, man kann also vielleicht eine Komponente für gemeinsame Funktionalität bauen. Die Suche muss irgendwie Daten aller anderen Komponenten indexieren können. Außerdem will man die Forenfunktionalität vielleicht noch nutzen, um über Artikel im CMS oder Wiki zu diskutieren.
Nun gibt es für all diese Dienste bestimmte Tabellen in der Datenbank. Was man jetzt natürlich nicht will, ist, dass z.B. die Suche direkt auf den CMS-Tabellen arbeitet. Andererseits muss der Suchindex aber irgendwie auf Dokumente verweisen können, ohne etwas über die genaue Art dieser Dokumente zu wissen, Dokumente die es nicht mehr gibt, müssen aus dem Index gelöscht werden etc. An dieser Stelle wird Architektur eigentlich erst komplex.
Wenn man nun ein Datenmodell und Objektmodell aus einem Guss hat, das all diese Anforderungen berücksichtigt, dann geht das alles sehr einfach. Die Anwendung ist aber nicht mehr modular.

Wie zentriere ich mich denn auf eine DB (== SQL?) Sie ist doch mehr oder minder "nur" Ablage für die Daten, mit denen ich hantieren möchte.

Naja, in einem beispielhaften, objektorientierten Programm gibt es Klassen, die den Ausschnitt der Realität beschreiben, mit dem die Anwedung arbeitet. Also Beispielsweise für ein CMS: Dokument, DokumentVersion, Benutzer, Abschnitt, ...
Diese Objekte sind Anwendungsspezifisch, gemeint ist also nicht etwa eine reine Darstellung des Datenformats wie ein XML-Baum o.ä.
In diesen Klassen ist die eigentliche Funktionalität realsiiert, also Dokumente anlegen, ändern etc.
Bei Webanwendungen passiert das oft alles direkt in der Datenbank. Es muss ja auch nicht unbedingt sinnvoll sein, große Objektgraphen aufzubauen, wenn man das gar nicht braucht.

MVC wird als Entwurfsmuster von Zend bezeichnet, glaub ich, und verlinkt.

Entwursmuster und Designpattern sind schon das gleiche. Der Begriff Designpattern wurde aber nicht für so konkrete Dinge wie MVC eingeführt, die eine Lösung für ein ganz konkretes Problem darstellen, sondern für abstraktere Lösungen. Eben Singleton, Factory, Visiter, Composite, etc.

Aha, so kam es mir auch vor. Ist es ja auch. Aber eine globale Variable gekapselt in einer Klasse ist ja so global nicht mehr.

Naja. Das Problem damit ist im wesentlichen, dass aller Code, der direkt auf so einen Sigleton zugreift, gar nicht mehr mit einem anderen Objekt aufgerufen werden kann, als dem, dass der Singleton zurückgibt. Man kann sich damit leicht die Flexibilität seines Codes zerschießen.
Beispiel: Oft wird z.B. eine Datenbankverbindung o.ä. als Singleton angelegt. Will man nun plötzlich mal seine Klassen dazu verwenden, um Daten von einer Datenbank in die andere zu kopieren, hat man ein Problem, weil man sie nicht mehr einfach zwei mal für verschiedene Datenbanken instanzieren kann.

pattern != Entwurfsmuster?

Entwurfsmuster sind einfach spezielle Muster, die englische Entsprechung ist wie gesagt Desgin Pattern.
Nun reden die Leute von Zend da tatsächlich von Design Patterns, ihre Quelle aber tut das nicht. Die nennt das "Patterns of Enterprise Application Architecture". Also Architekturmuster für einen ganz bestimmten Anwendungstyp.
Entwurfsmuster == Muster für eher kleine, lokale und allgemeine Probleme beim objektorientierten Entwurf.
Architekturmuster: Muster die die Gesamtarchitektur der Anwendung betreffen und eher problemspezifisch.

Ein Entwurfsmuster würde nie irgendwie Begriffe wie "graphische Darstellung", "Anwendungsdaten", "Anwendungslogik" etc. verwenden.

Wieso nicht? Dann liegen die Queries im Model, die Ausgabe in der View und dazwischen, ganz schlank, ein paar Verdrahtungen.

Eben, die Queries liegen dann im Modell. Damit hast Du gleich zwei Probleme: Erstens kann es schwierig sein, die Queries sauber einzelnen Modellklassen zuzuordnen und wahrscheinlich werden viele Queries Information über Tabellen fremder Modellklassen benötigen. Damit änderst Du möglicherweise etwas an der Implementierung einer Modellklasse und zugehöriger Tabelle und stellst dann fest, dass Du auch noch andere Klassen ändern musst.
Das zweite Problem ist: Du kannst nicht mehr so flexibel auf die Datenbank zugreifen, da Du nicht einfach mal schnell ein Query über mehrere Tabellen weg ausführen kannst, sondern nur mit den Operationen auskommen musst, die das Modell bietet. Man kann dann natürlich anfangen, komplexere Abfragemöglichkeiten in das Modell zu stecken, das vergrößert dann wieder das andere Problem.

Um Objektorientierung und Datenbanken zusammenzubringen, gibt es Object-Relation-Mapper. Vielleicht bietet Zend auch etwas in dieser Richtung? Da kann man dann Queries auf Objektebene formulieren und SQL wird im Hintergrund automatisch erzeugt. Damit kann man dann auch gleich ganze Objektgraphen aus der Datenbank holen oder Objekte automatisch aus der Datenbank nachladen, wenn man sie braucht.
Das ist zwar eine ganz praktische Sache, etwas achtsam sein, was denn nun wirklich wann wo geladen wird, muss man aber auch da.

Die Implementierung von Interfaces und Nutzung abstrakter Klassen geht ja ohne OOP wohl auch nicht, oder?

Ja, aber wofür verwendest Du diese Dinge? Für Controller, View, Actions usw? Oder auch um die Daten abzubilden?

Grüße

Daniel