Trennung von GUI und Logik, wie geht ihr vor?

[mkinzler]

https://blog.grijjy.com/2018/01/22/m...t-part-1-of-3/

[freimatz]

Daaaaaanke!
Unser Framework ist ähnlich aufgebaut.

[mkinzler]

2. Teil jetzt online

https://blog.grijjy.com/2018/01/24/m...t-part-2-of-3/

[hzzm]

Mal 'ne Frage:

Basierend auf den Diagrammen von
Model-View-Controller, Model-View-Presenter, Model-View-ViewModel,
speziell Figure 5:

Ist es MVP-gerecht, die "Observer<->Data Access"-Beziehung nicht zwischen Model<->View, sondern ueber den Mediator Presenter laufen zu lassen?
Der Presenter wuerde also das Model observen und bei notify in seiner View reagierend schalten, waehrend er von der View nach Strategy-Pattern Aenderungen direkt an das ihm gehoerende Model geben wuerde.

Waere das Passive vs. Supervising Presenter?
Oder gar kein MVP mehr?

Wenn das legitim ist, haette man ja wirklich null interaktion zwischen Model und View, sprich nur der Presenter waere noch Model-spezifisch.

Edit: Hat sich erledigt. Mit Mediator heisst es Model-View-Adapter

[QuickAndDirty]

@hzzm
Ich habe MVP immer so umgesetzt.
In der "program" Datei (*.dpr)
Werden die Presenter erzeugt.
Im Konstrukor der Presenter werden View und Model als Interface Parameter übergeben.
Im Konstruktor des Presenters werden View und Model dann mit eineander verdrahtet (Observer werden Registriert usw.)

Delphi-Quellcode:

KannWasPresenter := TKannWasPresenter.create((TKannWasView.create)as IKannWasView, (TKannWasModel.create) as IKannWasModel) as IKannWasPresenter;

Mein Presenter war immer ein reiner Gluecode-Container! Ich weiß nichtmal ob das so noch MVP heißt,
aber es hat echt gut funktioniert und es mir ermöglicht TModel in verschiedenen Projekten wieder zuverwenden.

Leider habe ich danach einen Ausflug in die Welt von MVVM und Livebindings gemacht :(
Und das war ein Fehler.
Meine Version von MVP hat mir echt mehr gebracht.

Jetzt habe ich mein MVVM projekt komplett von Livebindings befreit, weil ich zu dumm dafür bin....
Dadurch letzten Endes Viel Code in TForm Klassen und eine aufgeblähte VM Klasse dazwischen,
von der ich eigentlich nur die Navigations funktionalität bräuchte...

[hzzm]

Zitat:

Zitat von QuickAndDirty (Beitrag 1392364)

Leider habe ich danach einen Ausflug in die Welt von MVVM und Livebindings gemacht :(
Und das war ein Fehler.
Meine Version von MVP hat mir echt mehr gebracht.

Jetzt habe ich mein MVVM projekt komplett von Livebindings befreit, weil ich zu dumm dafür bin....
Dadurch letzten Endes Viel Code in TForm Klassen und eine aufgeblähte VM Klasse dazwischen,
von der ich eigentlich nur die Navigations funktionalität bräuchte...

Das haelt mich auch von MVVM ab. Wenn ich gaengige MVVM Implementationen lese, draengt sich mir immer ein Gedanke auf:

Over-engineered.

Suess in der Theorie, in der Praxis aber viel zu viel gefummele. Entkopplung muss auch einfacher gehen.