Webforms MVP Passive View - Ereignisbehandlung

Question

Sollte die Ansicht in ihrer Schnittstelle nichts ereignisspezifisches haben und den Moderator einfache Methoden aufrufen, um mit Ereignissen umzugehen und keine offiziellen Event-Handler zu haben? Zum Beispiel

// ASPX 
protected void OnSaveButtonClicked(object sender, EventArgs e) 
{ 
    _Presenter.OnSave(); 
} 

Oder sollte der Blick in seinem Schnittstelle Ereignisse Eventhandler definiert hat und die explizit verknüpfen Vorgänge steuern auf der Seite

// View 
    public interface IView 
    { 
... 
     event EventHandler Saved; 
... 
    } 

// ASPX Page implementing the view 
    protected override void OnInit(EventArgs e) 
    { 
     base.OnInit(e); 
     SaveButton.Click += delegate { Saved(this, e); }; 
    } 

// Presenter 
    internal Presenter(IView view,IRepository repository) 
    { 
     _view = view; 
     _repository = repository; 
     view.Saved += Save; 
    } 

Die zweite scheint wie eine ganze Reihe von Sanitär-Code hinzufügen überall.

Meine Absicht ist es, die Vorteile jedes Stils zu verstehen und nicht nur eine allgemeine Antwort zu verwenden. Meine Hauptziele sind Klarheit und hohe Testbarkeit. Testbarkeit insgesamt ist wichtig, aber ich würde Design Einfachheit und Klarheit nicht opfern, um in der Lage zu sein, eine andere Art von Test hinzuzufügen, die nicht zu viel Gewinn über die Testfälle hinaus führt, die bereits mit einem einfacheren Design möglich sind. Wenn eine Design-Option mehr Testbarkeit bietet, fügen Sie bitte ein Beispiel (Pseudo-Code ist in Ordnung) der Art von Test, die es jetzt bieten kann, so kann ich meine Entscheidung treffen, wenn ich diese Art von Extra-Test genug bewerten. Vielen Dank!

Update: Braucht meine Frage weitere Klärung?

Answer 1

In der Benutzeroberfläche Ihrer Ansicht sollten Sie einen Verweis auf die Schaltfläche "Speichern" haben, und dann wird alles in der Präsentation ausgeführt. So bleibt Ihr Blick frei von Code und Ihr Tester ist leicht testbar.

// View interface 
public interface IView 
{ 
    Button SaveButton; 
} 

// View code behind 
public Button SaveButton 
{ 
    get { return btnSave; } 
} 

// Presenter 
internal Presenter(IView view,IRepository repository) 
{ 
    _view = view; 
    _repository = repository; 
    view.SaveButton.Click += new EventHandler(Saved);; 
} 

void Saved(object sender, EventArgs e) 
{ 
    // do save 
} 

'

Answer 2

Wir haben gerade MVP mit Webformulare implementiert, und entschied sich für die einfachere Möglichkeit, auf dem Moderator die Ansicht Methoden aufrufen, die direkt für die Schaltfläche Ereignisse usw.

Unsere Rechtfertigung ist, dass Wir können die Ansicht trotzdem nicht direkt testen (wir verwenden diese Ebene zum Testen). Das Hauptziel ist also, einen Unit Testable Presenter zu haben, der so weit wie möglich vom View/Model getrennt ist.

Aus meiner Erfahrung werden Sie in WebForms aufgrund der Natur des Biests niemals einen komplett sauberen MVP erreichen (sie würden Sie wirklich lieben, diesen Code hinter der Datei zu verwenden ...), also würde ich nicht bleib nicht hängen.

Am Ende des Tages, müssen Sie die Gründe für die Trennung aus der Ansicht und Präsentationslogik bewerten und festzustellen, ob entweder Methode Sie wird später helfen/behindern ....

Answer 3

I don‘ t wie einen expliziten Verweis auf einen Button (oder ein anderes Steuerelement) in der Schnittstelle. Dies bedeutet, dass wir eng an die Implementierung der Kontrolle (n) gebunden sind.

Steuerelemente können sehr unterschiedlich zwischen Projekttypen (Winforms und ASP zum Beispiel) implementiert werden.

Dies bedeutet, dass die Schnittstelle möglicherweise für verschiedene Ansichten geändert werden müsste, was genau das ist, was wir nicht wollen. Der Kern von MVP ist, dass der Presenter auf eine stabile Schnittstelle zurückgreifen kann, die eine Trennung der UI vom Modell, eine einfache Substitution von konkreten Ansichten und Testbarkeit ermöglicht.

Besser, mit Eigenschaften und Methoden auf der Schnittstelle zu bleiben, die nicht von bestimmten Steuerelementen abhängen und die Implementierungsdetails den konkreten Ansichten überlassen.