Mediator-Model

[Gast2]

Hallo,

ich hab gerade ein Konzept kennen gelernt und wollte mal so nachfragen ob jemand schon damit Erfahrungen gemacht und generell einfach die Meinung darüber, was Ihr davon haltet.

Also es gibt einen Mediator(Service), welcher die BU Logik enthält und Zugriff auf das Model hat...Das Model(DAO) beinhaltet den Datenzugriff ,unter anderem mit Zugriff auf die Datenbank(z.B. SQL,HSQL usw.). Das Model greift auf die Domainobjekte(Fachklassen) zu, welche Peristient gemacht werden und die DB kommen.

Meine 2 Fragen, die ich mir zu dem Konzept stelle.
Was der Mediator für Vorteile hat, das Model hat keine Bu-Logik mehr das macht alles der Mediator?!
Ist es üblich, dass Model direkt SQL usw. befehle absetzt?

Gruß

 

[maki]

Mediator gehört zu den klassischen GOF Patterns: Mediator pattern - Wikipedia, the free encyclopedia

Was mich verwirrt ist die Zuordnung von Model, imho wären die Domain-/Fachklassen das Model, wenn man so möchte, aber in diesem Kontext ("Backend") ist MVC sowieso nicht mehr anwendbar.

Was meinst du denn genau mit "Modell"?

 

[Gast2]

z.B. du hast eine Fachklasse Person(Name, Vorname)
dann kann das Model mehrere Personen beinhalten und eventuell weitere Fachklassen...
Vielleicht hab ich auch was falsch verstanden?!?!
Warum wie würde bei dir ein Model aussehen?
Also in den Fachklassen stehen dann die ganzen Sachen(z.B. Hibernate - Annotations) die zum peristieren gebraucht werden, das machst ja nichts in Model rein oder?

Ah dann muss ich mir des mal genauer anschauen wenn das ein Pattern ist...

 

[maki]

Das sog. "Model" ist eigentlich ein Term aus MVC, und MVC gibt es nur in der Präsentationsschicht.

Im "Backend" kann man natürlich Model als Synonym für die Domänen-/Fachklassen nehmen, daher meine Verwirrung.

Das Pattern ist allgemein gehalten und hat von Haus aus erstmal nichts mit DAO/Services etc. zu tun.

Für mich hört sich das nach dem sog. "Transaction Script" Enterprise Pattern von Folwer an: P of EAA: Transaction Script

PEAA ist übrigens ein Klassiker, nicht Java spezifisch, deswegen allgemein gehalten, aber ein Buch dass man nicht missen sollte im Enterprise Bereich, ist aber keine leichte Kost, dafür soz. "ewig" gültig.
Auch ist es um einiges ausführlicher als die stark zusammengestutzte Version auf Fowlers Webseite, letztere ist eigentlich nur eine minimal Referenz.

Erkennen kann man das sog. Transaction Script daran, dass die gesamte Logik im Service (manchmal auch Manager genannt) steht, die Fachklassen sind nur dumme POJOs mit Gettern und Settern. Die DAOs werden vom Service aufgerufen. Für jeden Anwendungsfall (Transaktion) gibt es eine Methode im Service, pro Fachbereich einen Service.
Ist eher prozedural als OO.

Ps: Fowler nutzt den Begriff "Mediator" öfters in PEAA, soz. als "Vermittler".

 

[Gast2]

Das mit dem Model hab ich jetzt nicht ganz vertsanden.
Für dich sind die Fachklassen dein Model, also schreibst du in deinem Model. z.B. die ganzen z.B. hibernate sachen rein???

Also wie gesagt das Model(vielleicht ist Provider noch ein gutes Wort) beihnaltet wie du sie beschrieben hast POJOS mit get/set Methoden und eventuell Beziehungen zu den anderen POJOS und dort sind noch die ganzen Hibernate Annotations drin.

 

[maki]

Für dich sind die Fachklassen dein Model, also schreibst du in deinem Model. z.B. die ganzen z.B. hibernate sachen rein???

Nun, es heisst Domänenmodell (Domain Modell), deswegen ja, manche nennen sie auch POJOs (obwohl es streng genommen Unterschiede gibt die hier aber nicht relevant sind sondern nur noch mehr verwirren würden).
Kann sein dass wir nur unterschiedliche Begriffe für dieselben Dinge nehmen.

"hierbnate sachen" -> Annotationen?

Denn DAOs gehören nicht zum Modell, sondern zur Persistenzschicht, CRUD Operationen eben.

Also wie gesagt das Model(vielleicht ist Provider noch ein gutes Wort) beihnaltet wie du sie beschrieben hast POJOS mit get/set Methoden und eventuell Beziehungen zu den anderen POJOS und dort sind noch die ganzen Hibernate Annotations drin.

Ja, wobei ich davor zurückschrecke jetzt noch einen Begrtiff (Provider) einzuführen, ist schon verwirrend genug.

 

[Gast2]

Ja so wie es mir erklärt wurde verwirrt mich grad einiges...
Darum kann schon sein, dass ich falsche Begriffe benutze ^^.
Da ich das Pattern nicht kannte wurde es mir so erklärt(was ja nicht heißt das alles richtig) ist.
Und da wurden die Wörter Model(DAO) und Domainklassen(Fachklassen) benutzt.
und die CRUD Operationen stehen im Model und die Annotaions für Hibernate in den Fachklassen.

Wenn du ein einfach kurzes Beispiel auf Lager hast kannst es auch daran zeigen/beschreiben/coden, dann seh ich es vielleicht besser was du meinst =)...

 

[maki]

Code habe ich auf die schnelle nicht, denke aber das bei euch das "Model" für DAO steht, ziemlich sicher sogar.

Versuche mir mal ein Beispiel aus den Fingern zu saugen, als Text, User Speichern:
Client (Swing/JSF ManagedBean/etc.) ruft den Service auf: UserService.save(User newUser)
Die save Methode des UserServices bekommt den neuen User als Parameter übergeben (POJO, Domänenobjekt) und ruft die Save Methode des UserDaos auf (UserDao.save(User newUser) und übergibt diesem wiederum den neuen User.

Bei komplexeren Use Cases nutzt der Service mehrere DAOs.