AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Grundsaetzliche Struktur bei MV*

Ein Thema von hzzm · begonnen am 7. Mai 2018 · letzter Beitrag vom 8. Mai 2018
Antwort Antwort
hzzm

Registriert seit: 8. Apr 2016
103 Beiträge
 
Delphi 10 Seattle Professional
 
#1

Grundsaetzliche Struktur bei MV*

  Alt 7. Mai 2018, 09:28
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;
  Mit Zitat antworten Zitat
TiGü

Registriert seit: 6. Apr 2011
Ort: Berlin
3.070 Beiträge
 
Delphi 10.4 Sydney
 
#2

AW: Grundsaetzliche Struktur bei MV*

  Alt 7. Mai 2018, 11:49
Wäre über eine Factory ggf. möglich sich die Singleton-Instanz geben zu lassen.
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.016 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#3

AW: Grundsaetzliche Struktur bei MV*

  Alt 7. Mai 2018, 16:33
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.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
hzzm

Registriert seit: 8. Apr 2016
103 Beiträge
 
Delphi 10 Seattle Professional
 
#4

AW: Grundsaetzliche Struktur bei MV*

  Alt 8. Mai 2018, 08:55
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?


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.

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.

Geändert von hzzm ( 8. Mai 2018 um 10:34 Uhr) Grund: Okay, ich hab' in dem verlinkten Beispiel was uebersehen
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.016 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#5

AW: Grundsaetzliche Struktur bei MV*

  Alt 8. Mai 2018, 10:52
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).
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight

Geändert von Stevie ( 8. Mai 2018 um 10:55 Uhr)
  Mit Zitat antworten Zitat
hzzm

Registriert seit: 8. Apr 2016
103 Beiträge
 
Delphi 10 Seattle Professional
 
#6

AW: Grundsaetzliche Struktur bei MV*

  Alt 8. Mai 2018, 12:29
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.
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.016 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#7

AW: Grundsaetzliche Struktur bei MV*

  Alt 8. Mai 2018, 12:52
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/
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 11:03 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz