Webforms MVP Passive View - gestion des événements

Question

La vue n'a-t-elle aucun événement spécifique dans son interface et appelle-t-elle les méthodes simples du présentateur pour gérer les événements et ne pas avoir d'EventHandlers officiels? Par exemple

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

Ou devrait l'avis ont gestionnaires d'événements d'événements définis dans son interface et relier les haut explicitement pour contrôler les événements sur la page

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

La deuxième semble que beaucoup de code de plomberie pour ajouter partout.

Mon intention est de comprendre les avantages de chaque style et pas seulement une réponse générale à utiliser. Mes principaux objectifs sont la clarté et la testabilité de haute valeur. Dans l'ensemble, la testabilité est importante, mais je ne sacrifierais pas la simplicité et la clarté de la conception pour pouvoir ajouter un autre type de test qui n'amène pas trop de gain par rapport aux cas de test déjà possibles avec une conception plus simple. Si un choix de conception fait plus de testabilité, veuillez inclure un exemple (le pseudo code est correct) du type de test qu'il peut maintenant offrir afin que je puisse prendre ma décision si j'apprécie assez ce type de test supplémentaire. Merci!

Mise à jour: Ma question nécessite-t-elle d'autres précisions?

Answer 1

Dans l'interface de votre vue, vous devriez avoir une référence au bouton de sauvegarde et tout est fait dans le présentor. Cela maintient votre vue libre de code et votre présentateur facilement testable.

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

Nous avons juste mis en œuvre MVP en utilisant webforms et opté pour l'option plus simple d'avoir les méthodes d'appel de vue sur le présentateur directement pour des événements de bouton, etc.

Notre justification est que nous ne sommes pas en mesure de tester directement la vue de toute façon (nous utilisons waitin pour tester cette couche), donc l'objectif principal ici est d'avoir un présentateur testable unitaire qui soit aussi éloigné que possible de la vue/du modèle. D'après mon expérience, vous n'allez jamais arriver à un MVP complètement propre dans WebForms de toute façon en raison de la nature de la bête (ils aimeraient vraiment que vous utilisiez ce code derrière le fichier ...), donc je ne le ferais pas Ne vous attardez pas dessus.

A la fin de la journée, vous avez besoin d'évaluer les raisons de la séparation de la vue et la logique de présentation et de déterminer si une ou l'autre méthode va aider/vous gêner plus tard ....

Answer 3

Je ne J'aime avoir une référence explicite à un bouton (ou à tout autre contrôle) dans l'interface. Cela signifie que nous sommes étroitement liés à la mise en œuvre du (des) contrôle (s).

Les contrôles peuvent être implémentés très différemment entre les types de projet (Winforms et ASP par exemple). Cela signifie que l'interface devrait potentiellement être modifiée pour différentes vues, ce qui est exactement ce que nous ne voulons pas. Le point de MVP est que le présentateur peut compter sur une interface stable qui permet de séparer l'interface utilisateur du modèle, la substitution facile de vues concrètes et la testabilité.

Mieux vaut s'en tenir aux propriétés et aux méthodes de l'interface qui ne dépendent d'aucun contrôle spécifique et laisser les détails d'implémentation aux vues concrètes.