Model View Presenter

[Laurin Stoll]

Hallo zusammen,

Siehe da einmal wieder am Programmieren und schon bin ich wieder am
philosophieren.
Ich habe ein kleines Problem und ich bin mir nicht ganz einig, was ich
schöner finden soll. Ich habe zwei Variaten ein MVP Pattern
anzukicken:

1) Über die View:

AdministrationView dlg = new AdministrationView();
dlg.ShowDialog();

d.h. die View Intern macht:

public class AdministrationView : IAdministrationView
{
public AdministrationView()
{
this._presenter = new AdministartionPresenter(this);
}
}

oder

2) Über den Presenter:

AdministrationPresenter presenter = new AdministrationPresenter(new
AdministrationView()) // Natürlich könnte diese Initiailisierung auch
über default ctor oder Service Locator passieren...

Ich weiss nicht was mir besser gefallen soll? Beim 1) habe ich nicht
die volle Kontrolle über die Form, 2) scheint mir dafür aber
natürlicher da der Presenter eigentlich die Kontrolle hat und auch den
Anstoss bekommen soll....

Was meint ihr? Vor- und Nachteile?

Beste Grüsse
Laurin

[Björn Rochel]

Hi Laurin,

ich habe schon mal mit beiden Varianten gearbeitet und würde auf Basis
der umgebenden UI-Architektur wählen.

Ich habe mal eine Anwendung geschrieben deren Präsentationlayer-Logik
komplett um ein IPresenter-Interface aufgebaut war (Screen-Aktivierung/
Deaktivierung, etc.) und sehr stark
auf Basis von einem IoC aufsetzte. Für diese Art von Architektur halte
ich Variante 2 ebenfalls für die natürlichere, da der Presenter ein
wesentliches Steuerungselement der Architektur war.

In meinem Aktuellen Projekt habe ich leider nicht so einen Test-
freundlichen GUI-Layer zur Verfügung. Hier wird leider sehr viel auf
Ebene der Controls gemacht. Bevor ich in das Projekt gekommen bin, hat
da auch keiner was mit MVP gemacht. Hier mache ich aktuell Variante 1,
da Konsumenten-Code direkt mit der View arbeitet, der Presenter imho
ein Implementierungsdetail der Komponente ist und damit den
Konsumenten eigentlich nicht interessieren sollte . . .

Letztendlich aber, wie Du schon gesagt hast, ne Geschmacksfrage . . .

VG
Björn

[Laurin Stoll]

Hey Björn,

Danke für deine schnelle Antwort :-)

Hm... vom testen her ist Variante zwei wohl fast angenehmer....
Was mir halt einfach nicht passt ist wie ich die Form handle im
Presenter.
Der ctor des Presenters sieht ja irgendwie so aus:

public AdminPresenter(IAdminView view)
{
}

Und irgendwo muss ich diese View dann in eine Form konvertieren damit
ich ShowDialog aufrufen kann. Das mag ich nicht :-/ Diese casterei....
Aber wird wohl bei einer geschmackssache bleiben...

setzt jemand von euch eingentlich MVC bei WinForms noch ein? Ich
bevorzuge das MVP stark....

grüssle

[Kurt Häusler]

Laurin Stoll wrote:
>
> public AdminPresenter(IAdminView view)
> {
> }
>
> Und irgendwo muss ich diese View dann in eine Form konvertieren damit
> ich ShowDialog aufrufen kann. Das mag ich nicht :-/ Diese casterei....
> Aber wird wohl bei einer geschmackssache bleiben...

Du kannst ShowDialog in IAdminView zusätzlich deklarieren, oder ein
Wrapper Method implementieren.

[Laurin Stoll]

Ja da hast du recht. Nur muss ich dann ShowDialog und Show wrappen,
das gefällt mir auch nicht so...

du siehst schon ich bin nicht zufrieden zu stellen ^^ ;-)

Na ist wohl halt so... schade

[Björn Rochel]

@Laurin

> Hm... vom testen her ist Variante zwei wohl fast angenehmer....
> Was mir halt einfach nicht passt ist wie ich die Form handle im
> Presenter.
> Der ctor des Presenters sieht ja irgendwie so aus:
>
> public AdminPresenter(IAdminView view)
> {
>
> }

Welche Tests meinst Du da genau? Die des Konsumenten-Codes oder die
des Presenters?

Falls Du den Konsumenten-Code meinst gebe ich Dir recht, wenn Du eine
weitere Indirektion dazwischen hast (z.b. ne Factory für den Presenter
oder den IoC). Damit bist Du in der Lage das ganze durch Test-Doubles
zu ersetzten und den Konsumenten-Code isoliert zu testen. Soweit so
gut.

Falls Du den Test des Presenters meinst sehe ich da ehrlich gesagt
keinen Unterschied. Sieht der Presenter nicht in beiden Varianten
gleich aus? Variante 1 und 2 unterscheiden sich doch nur durch die
Integration in die View bzw. den unterschiedlichen Konsumenten-Code.

> Ja da hast du recht. Nur muss ich dann ShowDialog und Show wrappen,
> das gefällt mir auch nicht so...

Ach, halte ich eigentlich für nicht so schlimm. Pack das ganze in nen
Presenter - LayerSuperType und dann ist das eigentlich ganz angenehm
zu benutzen.

public interface IStandardView
{
DialogResult ShowDialog();
}

public class Presenter<TView> where TView : IStandardView
{
protected Presenter(TView view)
{
View = view;
}

TView View { get; private set; }

public DialogResult Show()
{
return View.ShowDialog();

}
}

> setzt jemand von euch eingentlich MVC bei WinForms noch ein? Ich
> bevorzuge das MVP stark....

Ich habe in der Vergangenheit in WinForms-Apps oft MVP gemacht und
fühle mich da von allen UI-Patterns auch am wohlsten. Hab früher
strikt Passive-View gemacht (um die View so dumm wie möglich zu
halten). Mit dem Alter kommt Gelassenheit und inzwischen setzte ich
eigentlich bei größeren Views eher Supervising Controller ein. Ist vom
Doing einfach angenehmer.

Interessant in der Hinsicht ist, dass MVP sich in WPF irgendwie nicht
mehr so gut anfühlt (wobei ich da auch grad erst mit dem Lernen
angefangen hab). Mittlerweile beginne ich zu verstehen, warum
PresentationModel sich in WPF zum Standard-Pattern entwickelt
hat . . .

VG
Björn

[Laurin Stoll]

Hi Björn :-),

> @Laurin

> Welche Tests meinst Du da genau? Die des Konsumenten-Codes oder die
> des Presenters?

Ich meine den Konsumenten-Code.

> Falls Du den Test des Presenters meinst sehe ich da ehrlich gesagt
> keinen Unterschied. Sieht der Presenter nicht in beiden Varianten
> gleich aus? Variante 1 und 2 unterscheiden sich doch nur durch die
> Integration in die View bzw. den unterschiedlichen Konsumenten-Code.

Das ist klar. Der Presenter sieht dabei ja genau gleich aus.

> Ach, halte ich eigentlich für nicht so schlimm. Pack das ganze in nen
> Presenter - LayerSuperType und dann ist das eigentlich ganz angenehm
> zu benutzen.
>
> public interface IStandardView
> {
>       DialogResult ShowDialog();
>
> }
>
> public class Presenter<TView> where TView : IStandardView
> {
>      protected Presenter(TView view)
>      {
>          View = view;
>      }
>
>      TView View { get; private set; }
>
>      public DialogResult Show()
>      {
>           return View.ShowDialog();
>      }
>
> }

Ja gut, damit könnte ich dann auch leben, hast du recht.

> Ich habe in der Vergangenheit in WinForms-Apps oft MVP gemacht und
> fühle mich da von allen UI-Patterns auch am wohlsten. Hab früher
> strikt Passive-View gemacht (um die View so dumm wie möglich zu
> halten). Mit dem Alter kommt Gelassenheit und inzwischen setzte ich
> eigentlich bei größeren Views eher Supervising Controller ein. Ist vom
> Doing einfach angenehmer.

Das geht mir sehr ähnlich. Gerade wenn viele Datenfelder einbezogen
sind ist mir Passive View zu anstregend. Bei kleineren Views bevorzuge
ich aber passive View nach wie vor.

> Interessant in der Hinsicht ist, dass MVP sich in WPF irgendwie nicht
> mehr so gut anfühlt (wobei ich da auch grad erst mit dem Lernen
> angefangen hab). Mittlerweile beginne ich zu verstehen, warum
> PresentationModel sich in WPF zum Standard-Pattern entwickelt
> hat . . .

Ja MVVM ist sehr cool in WPF. Vorallem zusammen mit Microsoft
Expression Blend. Wenn du im MVVM dann deine Aktionen auch noch per
Commands verfügbar machst kannst du in Blend sogar einfach
Drag'n'Dropen. Das ist echt cool!

Viele Grüsse
Laurin