Hellihello Daniel,

merci für Deine Ausführungen.

Gruppe gruppe = BenutzerVerwaltung.getGruppe("name");
Benutzer[] benutzer = gruppe.getBenutzer();
Dazu müsstest Du intern zwei SQL-Queries ausführen: "select * from gruppen where name='name'" und "select * from benutzer as t1, gruppen2benutzer  as t2 where t1.id = t2.benutzer and t2.gruppe = gruppenid".

Mit SQL könntest Du direkt so etwas machen:
"select * from benutzer as t1, gruppen2benutzer as t2, gruppen as t3 where t1.id = t2.benutzer and t2.gruppe = t3.id and t3.name = 'gruppenname'"

Das lässt sich beliebig verkomplizieren, sodass Du beim objektorientierten Fall viel mehr Queries brauchst als bei direkter Verwendung von SQL.

Ja, sowas schwante mir doch.

Hier verstehe ich vermutlich erst, wenn mir das mal wirklich unter die Finger kommt. Eine Abfrage über Tabellen hinweg könnte doch von einer weitern Klasse realisiert werden, die dann auf die "Tabellen"-Klassen zugreift, dachte ich.
Richtig, aber es ist oft weniger effizient. Siehe obiges Beispiel. Das führt dazu, dass man letzten endes alle Joins auf dem Objektmodell berechnet, statt das von der Datenbank machen zu lassen.

Was wiederum heißt, dass das dann bei den Controllern liegt, "SQL zu können".

Zend bietet nur "V" und "C", kein "M". "model can be anything".
Ja, das heißt wohl "Model muss man selber machen" oder eben gar nicht. Wobei gar nicht je nach Anwendung durchaus sinnvoll sein kann, nach meiner Auffassung.

Ich fand die Stellen dazu auch erstmal nicht unüberzeugend.

interface My_Model_Interface
{
    function getForm();
    function create();
    function read();
    function update();
    function getList();
}

> Das sieht ziemlich prozedural aus.  
  
Was daran ist denn "prozedural"? Oder anders: welche Funktion wäre nicht prozedural? Das getBenutzerForGruppe()?  
  
  

> Ja, aber er könnte keine Abfrage formulieren, für die Du keine Methode vorgesehen hast. Damit musst Du letzten endes alle erdenklichen Abfragen als Funktionen bereitstellen. Wenn eine neue Komponete eine weitere Abfrage braucht, musst Du diese hinzufügen, Du kannst sie nicht in der Komponente selbst implementieren.  
  
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. Ich hänge irgendwie an dem XML unter anderm der schönen xpath-queries wegen und aber auch der human-readability wegen. Und dachte aber: wer weiß, wird das irgendwann mal zuviel für xml, brauch ich wegen Schnelligkeit oder Zugriffskontrolle doch lieber SQL, könnte ich umstellen. Aber das Erfinden eigener Query-Syntax in den Klassenmethoden ist mir auch nicht wirklich geheuer.  
  

> > Zeichnet sich Modulariät nich dadurch aus, dass man immer die Möglichkeit hat, weitere Schnittstellen anzubieten (zB. innerhalb des Models) um Spezialaufgaben an u.U. neue Klassen zu deligieren, \_ohne\_ die bereits vorhanden Klassen dadurch zu berührern?  
> Ja und dadurch, die Implemetierung bestehender Klassen ändern zu können, ohne darauf aufbauende Klassen ändern zu müssen. Das erfüllt Dein Ansatz aber nur eingeschränkt, Du musst Die Modell-Klasse ändern, wenn der Controller weiter Abfragen ausführen muss.  
  
Aber wäre das nicht ein Singel-Point-Of-Change in der abstrakten Modelklasse?  
  

> Wenn Du mehrere Modell-Klassen für unterschiedliche Funktinalitäten hast (Beispiel: Benutzerverwaltung, Dokumentverwaltung) gibt es zudem keinen logischen Ort, wo man bestimmte Queries unterbringen könnte. Wenn Dokumenten beispielsweise eine Benutzergrupppe zugeordnet ist, die das Dokument ändern darf, hätte man eventuell gerne so eine Funktion:  
> boolean canUserChangeDocument(docid, userid);  
> Wenn man das wieder mit einem SQL-Query bestimmen will, muss man wissen, wie Benutzer und Gruppen zugeordnet werden und wie Dokumente Gruppen referenzieren. Bringt man die Methode in der Klasse für Dokumente unter, muss man diese Klasse ändern, sobald man z.B. die Benutzerverwaltung so ändert, dass Gruppen wiederum Gruppen enthalten können o.ä. Bringt man die Methode in der Klasse der Benutzerverwaltung unter, hat man die Methode da drin, selbst wenn man die Komponente Dokumentenverwaltung gerade gar nicht benötigt. Ändert man etwas an der Dokumentenverwaltung, z.B. mehrere Gruppen können einem Dokument zugeordnet werden, muss man zudem auch die Benutzerverwaltung ändern.  
> Das ist, was ich mit schlechter Modulariät meine.  
  
Grmpf.  
  

> Für eine typische Webanwendung aus einem Guss muss das wie gesagt kein Problem sein. Wenn man diese Modularität gar nicht braucht, kein Objektmodell braucht, um darauf irgendwelche komplexeren Verfahren zu implementieren, dann ist Dein Ansatz durchaus eine vernünftige herangehensweise. Man muss die Dinge ja nicht komplizierter machen, als sie schon sind.  
  
Hm.  
  

> Ich hab' gerade mal nach ORM-Werkzeugen für PHP gesucht und hab' das hier gefunden: [http://ezcomponents.org/docs/tutorials/PersistentObject](http://ezcomponents.org/docs/tutorials/PersistentObject)  
> Keine Ahnung, wie gut das ist, ich kenne solche Dinge nur von Java, beispielsweise: [http://www.hibernate.org/](http://www.hibernate.org/)  
> Auch ORM löst nicht alle Probleme und bringt auch erstmal zusätzliche Komplexität mit sich, es lohnt sich aber bestimmt, sich das mal anzusehen.  
  
Und ich fand noch <http://framework.zend.com/wiki/display/ZFPROP/Zend_Generator_Orm+-+Thomas+VEQUAUD> in <http://www.zfforums.com/zend-framework-general-discussions-1/general-q-zend-framework-2/zend-orm-268.html>  
  
  
Und auch <http://www.zietlow.net/zend-framework/mvc-model%E2%80%93view%E2%80%93controller-im-zend-framework/16/>  
  
"MVC im Zend Framework  
  
Das Zend Framework ist nach dem MFC Architekturmuster aufgebaut.  
Die MVC Theorie sollte klar sein, ab hier wird jetzt die technische Umsetzung im Zend Framework beschrieben.  
Model  
  
Derzeit – und ich denke auch in Zukunft – gibt es keine generelle Komponente für das Model.  
Wir wissen, dass das Model die Geschäftslogik und die Daten beinhaltet.  
  
Bei dem Model handelt es sich also um Klassen, die Daten aus Datenbanken, Web Services, Feeds, Konfigurationsdateien, Dateisystem und anderen Quellen „her holen“ und diese – je nach Geschäftslogik – verarbeiten.  
Das ist meist so individuell das es keinen Sinn macht das Model vorzuschreiben.  
  
Doch das Zend Framework bietet für die verschiedensten Zugriffe Unterstützung an, zum Beispiel:  
  
    \* Zend\_Db: auf Datenbanken zuzugreifen  
    \* Zend\_Service\_\*: Entsprechenden Webservices aufrufen  
    \* Zend\_Config: Konfigurationsdateien auszulesen"  
  
  
Dank und Gruß,  
  
[frankx](http://community.de.selfhtml.org/visitenkarten/view.php?key=82)

-- 
[tryin to](http://sauer-ernst.de) [multitain](http://multitain.de)  - Globus = Planet != Welt