Grundsaetzliche Struktur bei MV*

[hzzm]

Zitat von Stevie:

Somit wird höchstens SaftpresseController.pas ApfelController.pas benötigen und die entsprechende TSaftpresseController Instanz beim Erstellen die TApfelController Instanz bekommen (hier eignen sich z.B. Interfaces).

Das heisst, es gibt gar keine zwischen-unitlichen 'uses'-Beziehungen mehr, das ist dann nur noch fuer libraries.
Das Interface gibt nur genau die Resourcen frei, die die andere unit tatsaechlich benoetigt.

Wenn eine meiner Units 6 innere logische Zusammenhaenge braucht, hab' ich halt nen Konstruktor mit 8 Argumenten und 6 Interfaces, die ich pflegen muss.
Also bei hunderten von mini-frames/units, die einfach kleine "unter-Editoren" darstellen, nicht vorstellbar, ausser vielleicht fuer 15-30 "Haupt-Logiken".

Okay, danke fuer die Erklaerung.

[Stevie]

Zitat von hzzm:

Wenn eine meiner Units 6 innere logische Zusammenhaenge braucht, hab' ich halt nen Konstruktor mit 8 Argumenten und 6 Interfaces, die ich pflegen muss.
Also bei hunderten von mini-frames/units, die einfach kleine "unter-Editoren" darstellen, nicht vorstellbar, ausser vielleicht fuer 15-30 "Haupt-Logiken".

Das nennt sich dann auch "constructor overinjection" und kann durch Aggregation gelöst werden.
In den meisten Fällen sind viele Abhängigkeiten ein Zeichen für Nichteinhalten des SRP.

Siehe auch: http://blog.ploeh.dk/2010/02/02/Refa...egateServices/