Rolf B: Bild und Text kombiniert verschachteln

Beitrag lesen

Hallo MB,

wie PL schon schreibt - grundsätzlich gibt's bei OO die Vererbung und Referenzen auf andere Objekte. Vererbung scheint mir hier nicht zur Lösung beizutragen.

Um einem Objekt eine Referenz auf ein anderes Objekt zu verschaffen, gibt's verschiedene Wege. Der schlechteste ist, wenn sich ein Objekt die Referenz selbst holt, denn damit erzeugt man eine fest verdrahtete Beziehung zwischen den Objekten. Das ist nicht im Sinne der Informatik. Entkoppelung ist das Ziel, das schafft Testbarkeit und Austauschbarkeit.

Deswegen bekommt ein Objekt seine Referenzen auf andere Objekte sinnvollerweise von außen eingesetzt, das nennt man Dependency Injection. Es gibt Bibliotheken, die sowas per Deklaration automatisch tun, aber es geht auch manuell.

Dass ein Model eine Referenz auf ein Repository hält, ist allerdings merkwürdig. Eher sollte das Repository eine get oder suche Funktion haben, die das ArticleModel liefert. Analog muss das ListingRepository ein TListing Objekt liefern. Und der Controller steckt dann beides zusammen. Man kann Abhängigkeiten über den Konstruktur injizieren, oder durch Zuweisungen an öffentliche Properties.

Wenn Du in mehreren Controllern ArticleModel Objekte aufbauen musst, kann auch eine Klasse ArticleModelBuilder eine Lösung sein. Sie kennt die Repositories und weiß wie man den Objektbaum des ArticleModel zusammensetzt.

Wenn aber ArticleModel und TListing immer zusammen gehören, wenn ein TListing ohne ein ArticleModel gar nichts bedeutet, dann gehört das Ermitteln von TListing mit ins ArticleRepository. Die beiden bilden dann nämlich eine Business Domain, und ein Repository sollte sich mit einer BusinessDomain befassen, nicht mit einer Table.

Viele Wege führen zum Ziel. Jeder hat seine Vor- und Nachteile.

Rolf

--
sumpsi - posui - clusi