Table Module und Table Data Gateway - wer "besitzt" das Record Set

[PeterPetersen]

Hallo Forum,

bitte helft mir mal auf die Sprünge, ob/wie ich das Beispiel Sequenzdiagramm zum Muster "Table Module" in [PoEAA, S.127, Abb. 9.5 | oder hier] korrekt interpretiere:

1) Der Presenter (P) holt sich über einen Finder vom Table-Data-Gateway (TDG) ein Record-Set (RS)

2) P reicht dieses RS an ein Table-Modules (TM) weiter, welches seine Domain-Logik darauf appliziert

3) P reicht das so modifizierte RS an ein View (V) weiter, wo es ggf. durch den Benutzer weiter verändert wird

4) P reicht das aus 3) resultierende RS an das TM zwecks Validierung

5) P reicht das so validierte RS an das TDG zwecks Update in der Datenbank

Wenn ich das Beispiel richtig verstehe, "besitzt" also P das RS?! Sowohl TDG als auch TM müssten/sind nicht instanziiert - es könnten statische Methoden sein!?


Ich hatte es eigentlich so verstanden, dass der P mit dem TM kommuniziert, welches mit dem TDG kommuniziert (also P <-> TM <-> TDG <-> DB), zumal das TM ja auch ohne TDG umgesetzt werden könnte.

Dazu müsste aber das TM ja "Besitzer" des RS sein und ergo instanziiert? Würde in diesem Fall das TM das RS an den V weitergeben und damit dann eine Model-View-Presenter (Passive View) Architektur aufbrechen?

Sorry für die vielen Fragen - evtl. hab' ich auch einfach etwas ganz Grundlegendes nicht verstanden



[PoEAA - Martin Fowler, Patterns of Enterprise Application Architecture]

[Dejan Vu]

Was verstehst Du denn unter 'besitzen'?
Und vergiss mal ganz schnell 'statisch', das ist ein Anti-Pattern. Deine TDG, UVW, ABC und XYZ bekommt dein P z.B. über einen Service Container angeflanscht.

[PeterPetersen]

Mal angenommen ich iterpretiere das Sequenzdiagramm korrekt, dann würde ich im Presenter z.B. ein Feld "FRecordSet: OleVariant" schaffen, welches mein RS über die ganze Transaktion hinweg hält/besitzt/verwahrt ... wie sagt man es denn richtig?

[himitsu]

Besitzen ... ich würde mal denken, er meint damit den Owner, also den, welcher für die Speicher-/Instanzverwaltung und schlußendlich die Freigabe zuständig ist.

P holt es sich, P reicht es rum, lässt Andere damit was machen und gibt es am Ende hoffentlich auch wieder frei.

TM würde ich niemals in betracht ziehen, denn TM ist weder ganz am Anfang, noch am Ende beteiligt, sondern nur zwischendurch einmal ganz kurz.
Maximal TDG würde ich in Betracht siehen, da er das RS ja schließlich bereitgestellt hat.

Alternativ könnte es der Besitzer von P sein, aber eigentlich würde ich dennoch nur an P oder TDG denken.

[PeterPetersen]

Zum "Besitzen": so wie es himitsu meint - also der "Owner"

Falls das TM nun nicht instanziiert ist (oder wie Fowler es schreibt: "[...] a collection of static methods") ist mir das einigermaßen klar.

Nun kann TM aber auch instanziiert sein ("The advantage of an instance is that it allows you to initialize the Table Module with an existing record set") - hier stellte sich mir die Frage, wer ist jetzt der "Owner" vom RS (P oder TM) - und kennt TM das TDG?

[Dejan Vu]

Bei modernen Programmiersprachen muss dich das nicht interessieren, aber bei Delphi wäre das imho P. Alternativ arbeitest Du mit Interfaces, da musst Du dich dann auch nicht drum kümmern.

[himitsu]

Im NextGen müsste man das auch nicht.

Einfach nur noch ausschließlich für iOS und Android entwickeln und schon hat man andere Problem, aber Dieses hier ist dann weg.
Aber ja, alternativ alles in Interfaces kapseln.