Formularze WWW Widok pasywny MVP - obsługa zdarzeń

Question

Czy w widoku nie ma nic konkretnego dla konkretnego interfejsu i czy można wywołać prezentera zwykłymi metodami obsługi zdarzeń i nie mieć żadnych oficjalnych zdarzeń EventHandlers? Na przykład

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

Albo powinno widok nie EventHandlers zdarzeń określonych w jego interfejs i połączyć te się jawnie kontrolować wydarzenia na stronie

// 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; 
    } 

Drugi wydaje się dużo kodu wodociągowej dodać wszędzie.

Moim zamiarem jest zrozumieć korzyści płynące z każdego stylu, a nie tylko ogólną odpowiedź, której należy użyć. Moimi głównymi celami jest jasność i testowalność o wysokiej wartości. Ogólna testowalność jest ważna, ale nie poświęciłbym prostoty i jasności projektu, aby móc dodać kolejny typ testu, który nie prowadzi do zbyt dużego zysku w testach już możliwych dzięki prostszemu projektowi. Jeśli wybór projektu przestaje być bardziej testowalny, proszę podać przykład (pseudo-kod jest w porządku) typu testu, który teraz może zaoferować, więc mogę podjąć decyzję, jeśli wystarczająco cenię tego typu dodatkowy test. Dzięki!

Aktualizacja: Czy moje pytanie wymaga dodatkowych wyjaśnień?

Answer 1

W interfejsie widoku powinieneś mieć odwołanie do przycisku zapisu, a następnie wszystko odbywa się w prezencie. Dzięki temu twój widok jest wolny od kodu, a twój preseneter jest łatwy do sprawdzenia.

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

Właśnie realizowany MVP przy użyciu webforms i zdecydował się na prostszą możliwość posiadania metody widok wzywają prezenter bezpośrednio na imprezy przycisków itp

Nasze usprawiedliwienie jest to, że nie jesteśmy w stanie przetestować widoku bezpośrednio (używamy waitin do testowania tej warstwy), więc głównym celem jest tutaj testowalny prezenter jednostkowy, który jest odseparowany tak daleko jak to możliwe od widoku/modelu.

Z mojego doświadczenia wynika, że ​​nigdy nie uda ci się osiągnąć całkowicie czystego MVP w WebForms ze względu na naturę bestii (oni naprawdę chcieliby, żebyś użył tego kodu za plikiem ...), więc nie chciałbym Nie zwlekajcie z tym.

Pod koniec dnia, trzeba ocenić przyczyny oddzielenie widok i prezentacji logiki i określenia, czy też metoda pomoże/utrudniać Ci później ....

Answer 3

I don” T mieć wyraźne odniesienie do przycisku (lub jakiejkolwiek innej kontroli) w interfejsie. Oznacza to, że jesteśmy ściśle związani z wdrożeniem kontroli.

Kontrole można wdrażać w bardzo różny sposób pomiędzy typami projektów (na przykład WinForm i ASP).

Oznacza to, że interfejs wymagałby potencjalnej modyfikacji dla różnych widoków, co jest dokładnie tym, czego nie chcemy. Cały punkt MVP polega na tym, że prezenter może polegać na stabilnym interfejsie, który pozwala na oddzielenie interfejsu od modelu, łatwą zamianę konkretnych widoków i testowalność.

Lepiej trzymać się właściwości i metod interfejsu, które nie zależą od konkretnych elementów sterujących i zostawiają szczegóły implementacji w konkretnych widokach.