nicht angemeldet
Hallo frankx,
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.
Jau, man schreibt quasi ein Sub-SQL bzw. eben datenbankunabhängige Funktionen, die man dann in xpath oder sql-queries umwandelt. Wenn das aber alles in den Controllern landet, dann ließe sich aber das Datenbankmodell nicht modular austauschen, was ja vielleicht auch nicht sinnvoll ist.
Das Modell auszutauschen ist meist nicht sinnvoll. Ein Controller braucht ohnehin gewisse Information über das Modell. 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. Ein ORM kann durchaus auch ermöglichen, dass man Queries bezüglich bestimmter Schnittstellen formuliert.
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 ;-)
Aber wäre das nicht ein Singel-Point-Of-Change in der abstrakten Modelklasse?
Nein, der "Single-Point-Of-Change" sollte genau der Controller sein, indem die neue Funktionalität realisiert werden soll. 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.) 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.
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.
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.
"Derzeit – und ich denke auch in Zukunft – gibt es keine generelle Komponente für das Model. [...]"
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.
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.
* 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.
Grüße
Daniel