Hellihello Daniel,

Was daran ist denn "prozedural"? Oder anders: welche Funktion wäre nicht prozedural? Das getBenutzerForGruppe()?
Doch, sowas wie getBenutzerForGruppe() ganz besonders.
Prozedural ist die Schnittstelle, weil sie einfach eine Menge von Algorithmen zur Datenabfrage zur Verfügung stellt. Es kommt ein Aufruf mit Parametern rein und eine Menge von Daten zurück. Eine Objektorientierte Schnittstelle würde die Daten in Objekte strukturieren (die Benutzer- und Gruppen-Objekte im Beispiel) und die Algorithmen auf diese Objekte aufteilen.

Prozedural ist sie, weil sie selbst keine Eigenschaften hat? "Muss" ich jedes mal "new Benutzer($id)" machen oder innerhalb der Gruppe "new Gruppe ($groupName)" werden dann die Benutzer nach ihrer Gruppenzugehörigkeit geladen?

Wenn ich mit XML-Daten hantiere, kann ich in PHP mir die in SimpleXMLObjects laden, die selbst noch Methoden mitbringen wie ->hasAttributes() ->attributes() oder ->getName(); Das Model sollte eigentlich nur dazu dienen, diese XML-Objekte einzusammeln.

Das Modell auszutauschen ist meist nicht sinnvoll.

Das Modell meint jetzt die Datenstruktur und ihre Zusammenhänge (Benutzer mit all seinen Eigenschaften, Gruppen mit ihren n->m Relationen) oder mein Modell die Art der Speicherung (XML, SQL)?

Ein Controller braucht ohnehin gewisse Information über das Modell.

Die Frage wäre, so wie ich das sehe, was genau "gewisse" heißt. Nicht wissen muss der Contoller wohl, wie die DB heißt und wie er sich damit verbindet. Vom "Model" würde er wohl eben eine ResourceHandle erwarten, und dann die entsprechenden Queries machen, zumindest eine Variante, die mir in einer ZF-Beispielanwendung unter kam.

Man kann natürlich Klassen haben, die nur von bestimmten Eigenschaften des Modells abhängen, wozu man dann nur bestimmte Schnittstellen festlegt und Modelle müssen lediglich solche Schnittstellen implementieren, damit der Controller damit klar kommt.

Ja sowas dachte ich mit o.g. Ansatz irgendwie näher zu kommen.

Aber das Erfinden eigener Query-Syntax in den Klassenmethoden ist mir auch nicht wirklich geheuer.
Ja, ist erstmal etwas verwirrend, vor allem, weil man nicht immer so sicher ist, was da eigentlich genau passiert. Es ist aber ungemein nützlich ;-)

Mh, was ist daran "nützlich"? Und wieso ist man nicht so sicher, was da passiert? Model->getList("Benutzer) würde ein Array of SimpleXMLObjekts zurückgeben zB.. Model->get($Benutzer, $id) ein SXO des Benutzer mit der genannte ID. Ich könnte natürlich auch eine Benutzer-Klasse haben, die im Konstruktor die $id verwurstet (s.o.) und dann mit $Benuter->getName() dessen Namen ausgibt oder mit $Benutzer->update($params = array()) gewisse Eigenschaften setzt.

Nein, der "Single-Point-Of-Change" sollte genau der Controller sein, indem die neue Funktionalität realisiert werden soll.

Das heißt, die Modelklasse weiß nur, wie sie ein ResourceHandle herstellt? Also zB. dass die Datei für "Benutzer" "BenutzerData.xml" heißt und im Ornder "data" liegt? Das muss der Controller ja nicht wissen, oder?

Die Modelklasse wäre eine Klasse mit schlechtem Zusammenhalt, weil sie Funktionen mit unterschiedlichsten Aufgaben enthält. (Das wird auch oft als Kohäsion bezeichnet.)

Oder Single-Responsibility-Prinzip?

Man kann ja nicht einfach sagen, wenn ich alles in eine Klasse schmeiße, habe ich keinerlei Kopplung mehr zwischen Klassen und daher keinerlei Probleme mit Änderungen.

Nein, das war mir auch schon klar. Ich dachte halt, dass - vielleicht klappt das nur im kleinen Rahmen - der Conroller eben nur die Requests an die entsprechende Abfrage weitergibt. In meinem Fall wären das zB. Artists, Locations, Agencies, oder aber Schüler, Lehrer, Eltern. Die Profilanzeige würde sich aus den Eigenschaften ergeben und wäre ja eh Sache der View, Listenausgabe ungefiltert ist auch ident, und deshalb die Idee mit dem ->getList(). Der Controller könnte dann u.U. noch die Zugangsberechtigung checken (darf der und der das und das anzeigen, was bei Artists/Locations/Agencies weniger der Fall wäre, bei einem schulinternen(!) "...VZ" schon eher).

Und ich fand noch [...]
Dieser Zend Generator ORM scheint nur ein Codegenerator zu sein, der aus einem DB-Schema ein Klassenmodell macht oder umgekehrt. Das ist schon was, aber nicht besonders viel.

Heißt, zum Lernen gut, aber nicht optimiert?

» http://code.google.com/p/zend-framework-orm/ wurde in dem Thread erwähnt und das scheint ein bisschen was zu können. Dass es da allerdings eine Objekt-Query-Sprache gibt, kann ich nirgens sehen. Scheint also eher einfach zu sein. Object-Relation-Mapping kann recht kompliziert werden und dann muss das Werkzeug schon einiges können.

Auha, ich dachte, irgendwann hört das mal auf mit dem immer nochwas dazulernen müssen (;-).

Ja, da haben sie sicher recht, ein Modell kann man nicht vorgeben. Man kann allerdings die Serialisierung des Modells in Dateien oder Datenbanken unterstützen. Frameworks wie Zend machen das nach meinem Eindruck eher selten bis gar nicht. Manche Frameworks geben gewisse Regeln vor, wie Modellklassen zu definieren sind. RoR tut wohl so etwas und kümmert sich irgendwie wohl auch um OR-Mapping.

Na RoR baut doch gleich die Datenbank im Hintergrund auf, wenn ich das recht kapiert habe.

Es spricht aber auch nichts dagegen, ein Framework wie Zend zu nehmen und für das Modell irgend etwas anderes einzusetzen, vorausgesetzt es gibt für PHP etwas, das wirklich gut genug ist. Wenn man zuviel um die Schwächen eines OR-Mappers herumprogrammieren muss, dann bringt das wahrscheinlich nichts mehr.

Na ich suche einen Weg, mich da (modular) von einfach nach kompliziert hochzuarbeiten.

* Zend_Db: auf Datenbanken zuzugreifen
* Zend_Service_*: Entsprechenden Webservices aufrufen
* Zend_Config: Konfigurationsdateien auszulesen"
Nuja, bei all diesen Schnittstellen muss man Objekte von Hand abbilden. Das ist also kein Ersatz für einen ORM. Auch für Webservices gibt es ja solche Bibliotheken, die automatische Objekte in XML-Nachrichten konvertieren und zurück. Nun kommt es sehr auf den Webservice an, ob das wirklich sinnvoll ist. Wenn man Webservices aber als RPC-Ersatz verwendet, möchte man das eher nicht mehr von Hand tun.

http://de.wikipedia.org/wiki/XML-RPC noch so ein Fremdwort (;-).

Dank und Gruß,

frankx