Grundsaetzliche Struktur bei MV*

[hzzm]

Guten Morgen,

ich frage mich gerade, wo eine saubere Platzierung des Controller-Objekts bei der Verwendung von MV-X-Pattern ist:

Eigentlich muesste man den Controller doch global in der entsprechenden Unit instanzieren, oder?
Grundsaetzlich wird jedoch von globalen Variablen abgeraten, da diese unsaubere (oder unklare) Verlinkungen schaffen usw.

Aber ich will doch am Ende, dass ich aus einer anderen (neben-)Unit bei uses Kaese; Zugriff auf den Controller habe.
Gibt es dann ueberhaupt Alternativen?

Delphi-Quellcode:

Unit Kaese;

type
  TKaeseModel = class
    ABool: Boolean;
  End;

  TKaeseView = class
    TKaeseFrame: TFrame;
  End;

  TKaeseController = class
  private
    View: TKaeseView;
    Model: TKaeseModel;
  End;

var // !!!
  KaeseController: TKaeseController;

[TiGü]

Wäre über eine Factory ggf. möglich sich die Singleton-Instanz geben zu lassen.

[Stevie]

Mich verwirrt etwas, dass du zwar MV* schreibst und somit den Teil zwischen Model und View undefiniert lässt, dann aber von Controller sprichst.
Je nachdem, ob man MVC, MVP, MVVM, oder eine Eigenart dieser macht, ergibt sich auch, wie man den entsprechenden Teil (Controller, Presenter, ViewModel) erstellt und wer mit wem kommuniziert.

Grundsätzlich möchte ich aber von Singleton oder globaler Variable abraten, denn das führt die Verwendung des Patterns ad absurdum.

[hzzm]

Zitat von TiGü:

Wäre über eine Factory ggf. möglich sich die Singleton-Instanz geben zu lassen.

Waere moeglich, oder ist State-of-the-Art die Situation zu behandeln?
Wer gibt denn dann diese Controller-Instanzen raus? Main-Objekt haelt sie, alle neben-units (unter-units), die sich gegenseitig brauchen, holen sich Interfaced von Main dann die Nachbar-Controller-Instanz?
Bringt mir das seitens der ASM-Zugriffe nachher tatsaechlich Vorteile?

Zitat von Stevie:

wie man den entsprechenden Teil (Controller, Presenter, ViewModel) erstellt

Um ViewModel, Model, View oder Presenter geht es mir gar nicht. Dass sich diese Zusammenhaenge aus dem jeweiligen Pattern ergeben, ist schon klar.
Es geht nur um das ueberliegende Controller(-artige) Objekt.

Zitat von Stevie:

Grundsätzlich möchte ich aber von Singleton oder globaler Variable abraten, denn das führt die Verwendung des Patterns ad absurdum.

Okay, ich hab anscheinend irgendwas verpasst. Reden wir mal ueber MVC explizit:
Von diesem Beitrag:

Main project file:

Delphi-Quellcode:

var
  Model: TModel;
  Controller: TController;
begin
  Application.Initialize;
  Application.CreateForm(TMainForm, MainForm);

  Model      := TModel.Create;
  Controller := TController.Create(Model, MainForm);

  Application.Run;

  Controller.Free;
  Model.Free;
end.

Es bleibt - wie bei allen Beispielen die ich finde - unklar, wie auf benachbarte Controller-Instanzen zugegriffen wird.

Delphi-Quellcode:

var
  ApfelModel: TModel;
  ApfelController: TController;
  SaftpresseModel: TModel;
  SaftpresseController: TController;
begin
  Application.Initialize;
  Application.CreateForm(TMainForm, MainForm);

  ApfelModel      := TModel.Create;
  ApfelController := TController.Create(ApfelModel, MainForm);
  SaftpresseModel      := TModel.Create;
  SaftpresseController := TController.Create(SaftpresseModel, MainForm);

  Application.Run;

  ApfelController.Free;
  ApfelModel.Free;
  SaftpresseController.Free;
  SaftpresseModel.Free;
end.

Alles klar, aber inhaltlich benoetigt ist Apfel uses Saftpresse .
Und nun? Die beiden Controller liegen ja nur als fluechtige Instanzen so nebeneinander rum.

[Stevie]

Also erstmal solltest du dich von dem Gedanken verabschieden, dass zusammengehörige M, V und C in einer Unit liegen, das wird nur schief gehen.

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).

[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/