Présentateur modèle C # WinForms (présentation passive)

Voici un exemple simple qui illustre le concept de vues passives à l’aide du modèle de conception MVP. Comme nous utilisons des vues passives, la vue n’a aucune connaissance du présentateur. Le présentateur s’abonnera simplement aux événements publiés par la vue et agira en conséquence.

Pour commencer, nous devons définir un contrat pour notre sharepoint vue. Ceci est généralement réalisé en utilisant une interface, essentiellement, nous voulons avoir un couplage très lâche avec notre vue. Nous voulons pouvoir changer de vue ou créer des vues fantômes pour les tests unitaires.

Voici un contrat qui décrit une vue simple qui sera utilisée pour afficher les informations client

public interface ICustomerManagementView { void InitializeCustomers(ICustomer[] customers); void DisplayCustomer(ICustomer customer); event EventHandler> SelectedCustomerChanged; } 

Il expose une seule méthode InitializeCustomers qui sera utilisée pour initialiser notre vue avec des objects de notre modèle.

Nous avons également un événement SelectedCustomerChanged qui sera utilisé par notre présentateur pour recevoir une notification indiquant qu’une action a eu lieu dans la vue.

Une fois que nous avons notre contrat, nous pouvons commencer à gérer ces interactions dans notre présentateur.

 public class CustomerManagementPresenter { private ICustomer _selectedCustomer; private readonly ICustomerManagementView _managementView; private readonly ICustomerRepository _customerRepository; public CustomerManagementPresenter(ICustomerManagementView managementView, ICustomerRepository customerRepository) { _managementView = managementView; _managementView.SelectedCustomerChanged += this.SelectedCustomerChanged; _customerRepository = customerRepository; _managementView.InitializeCustomers(_customerRepository.FetchCustomers()); } private void SelectedCustomerChanged(object sender, EventArgs args) { // Perform some logic here to update the view if(_selectedCustomer != args.Value) { _selectedCustomer = args.Value; _managementView.DisplayCustomer(_selectedCustomer); } } } 

Dans le présentateur, nous pouvons utiliser un autre modèle de conception appelé dependency injection pour fournir un access à notre vue et à toutes les classes de modèle dont nous pourrions avoir besoin. Dans cet exemple, j’ai un CustomerRepository qui est chargé de récupérer les détails du client.

Dans le constructeur, nous avons deux lignes de code importantes. Premièrement, nous avons souscrit à l’événement SelectedCustomerChanged de notre sharepoint vue, c’est ici que nous pouvons effectuer des actions associées. Deuxièmement, nous avons appelé InitilaizeCustomers avec des données du référentiel.

Pour l’instant, nous n’avons pas encore défini d’implémentation concrète. Tout ce que nous avons à faire est de créer un object qui implémente ICustomerManagementView . Par exemple, dans une application Windows Forms, nous pouvons effectuer les opérations suivantes:

 public partial class CustomerManagementView : Form, ICustomerManagementView { public CustomerManagementView() { this.InitializeComponents(); } public void InitializeCustomers(ICustomer[] customers) { // Populate the tree view with customer details } public void DisplayCustomer(ICustomer customer) { // Display the customer... } // Event handler that responds to node selection private void CustomerTreeViewAfterSelect(object sender, TreeViewEventArgs e) { var customer = e.Node.Tag as ICustomer; if(customer != null) { this.OnSelectedCustomerChanged(new EventArgs(customer)); } } // Protected method so that we can raise our event protected virtual void OnSelectedCustomerChanged(EventArgs args) { var eventHandler = this.SelectedCustomerChanged; if(eventHandler != null) { eventHandler.Invoke(this, args); } } // Our view will raise an event each time the selected customer changes public event EventHandler> SelectedCustomerChanged; } 

Si nous voulions tester notre logique de présentation, nous pourrions nous moquer de notre sharepoint vue et effectuer certaines affirmations.

EDIT: arguments d’événement personnalisés inclus

 public class EventArgs : EventArgs { private readonly T _value; public EventArgs(T value) { _value = value; } public T Value { get { return _value; } } } 

Je les diviserais en vues séparées avec leurs propres cadeaux et utiliserais un présentateur / une vue “contrôlant” pour gérer la délégation de messages entre eux. Cela facilitera non seulement la testabilité, mais permettra également à vos contrôles de continuer à remplir leur SRP.

Donc, dans votre cas, vous pourriez avoir un IFormManager que votre fenêtre principale implémentera, puis un IFileManager, ILoggerWindow, etc.

Bien que cela puisse être un peu excessif à utiliser, je vous suggère de jeter un coup d’œil à Smart Client Software Factory (de l’équipe Microsoft Patterns and Practices). Est-ce que ce genre de composition de vues est assez bien, donc peut-être que vous pourriez avoir de bonnes idées.