Design-Pattern: Wie sieht eures aus?

[Gilles]

Hallo Leute,
Ich würde gerne mal eure Meinung zu verschiedenen Mehrtier-Architekturen wissen und in welche Teile Ihr eure Applikationen aufteilt.
Denn des öfteren höre ich von Vor- als auch nachteilen von verschiedenen Architekturen.
Derzeit verwende ich eine erweiterte MVC Architektur die wie folgt aufgebaut ist:

- Controller (Eingangspunkt)
- Model (wird von Controller aufgerufen)
- DataObject (repräsentiert ein Objekt mit all seinen Attributen und kann auch Beispielsweise auf eine Datenbanktabelle abgebildet werden. Besitzt Methoden wie: save, loadById oder delete. Ansonsten nur getter und setter (Entsprechend einer Bean im Java-Bereich))
- DAO (wird vom DataObject benutzt, um mit der Persistenzschicht zu kommunizieren. Kann ausgetauscht werden um mit verschiedenen System zu kommunizieren wie z.B. Mysql oder dem Filesystem)
- View (wird nach dem Model vom Controller aufgerufen)

Nun würde ich gerne von euch wissen, ob diese Architektur zu übertrieben ist, oder was man denn besser machen kann. Ich bin auch gerne für neue Sachen offen :)

 

[freak131]

irgendwie sind die schichten noch was durcheinander, was unterschiedet ein Model von einem DataObject, save() ist definitiv nichts was eine sture datenstruktur unterstützen sollte.


nur mal dezent als hinweis für dich als düsseldorfer:
https://www.xing.com/net/pria78fa4x/phpgroupd/

 

[crash]

DataObject scheint hier ein einfaches GRUD zu sein, während die DAO einfach den eigentlichen Speicher behandelt. Scheint meiner Ansicht nach völlig in Ordnung. Das DataObject wird sicher für jedes Wertepaar (meistens Zeilen) eine neues Model erzeugen (Stichwort: Mapper) und save() nimmt dann einfach ein Model und speichert die Daten aus dem Model ins DAO.

Ist meine Meinung nach völlig in Ordnung.

Bei mir sind das DataObject eben ein Mapper und die DAO ist Zend_Db bzw. etwas anderes (vorausgesetzt ich arbeite nicht mit Doctrine).

 

[Gilles]

Wie crash schon richtig erkennt hat, ist DataObject ein CRUD (GRUD würde ich nicht kennen. Verschrieben?) und die DAOs sind so etwas wie meine Treiber, die bestimmt werden, welches Objekt in der Persistenzschicht verwendet wird. (Hoffe ich verwechsle da nicht ein paar Wörter )
@freak131 es stimmt schon, dass meine DataObjects keine sturen Datenstrukturen sind, jedoch hoffe ich, dass es nicht all zu sehr von der Norm abweicht mit der save Methode. hier wird nur gefragt, ob das derzeitige Objekt eine eindeutige Zuweisung hat (zum Beispiel id) Wenn ja löst das save ein update aus, ansonsten wird das Objekt neu in der Persistenzschicht angelegt.

 

[freak131]

Hallo Leute,
- Model (wird von Controller aufgerufen)
- DataObject (repräsentiert ein Objekt mit all seinen Attributen und kann auch Beispielsweise auf eine Datenbanktabelle abgebildet werden. Besitzt Methoden wie:

irgendwie ist mir deine Trennung zwischen DataObject und Model nicht einleuchtend. Ein DataObject ist ja absichtlich so abstrakt gehalten, dass es nichts über seine Herkunft wissen muss, demnach sollte nach meiner Auffassung ein DataObject auch keinerlei methoden (bis auf Getter und Setter) implementieren sondern nur als nur als Transportstruktur für den Servicelayer dienen.

dem Model würde ich den Datenbanklayer "DAO" injizieren, schließlich sollte dem Model egal sein, wo es seine Daten ablegt.