MVP : Plusieurs vues/présentateurs pour un formulaire complexe (winforms) ?

Question

Je suis en train d'ajouter des fonctionnalités à un formulaire complexe dans une application existante. Il y a déjà un énorme formulaire avec beaucoup de contrôles et d'onglets et un énorme code derrière le fichier cs. J'essaie d'éviter de créer un énorme View/Presenter. Est-ce une bonne pratique d'ajouter une vue (et un présentateur) pour chaque fonctionnalité du formulaire ? Existe-t-il une meilleure solution ? Je ne peux pas séparer le formulaire en plusieurs formulaires à cause des exigences des utilisateurs.

La définition du formulaire se présente comme suit,

public partial class frmMyForm 
    : IView1, IView2, IView3, IView4, IView5, 
      IView6, IView7, IView8, IView9, IView10
{
    ....

Chaque IViewN est une fonction différente - par exemple, l'une est destinée à la comparaison visuelle des changements de données, l'autre à l'affichage des données dans les grilles, l'autre aux statistiques récapitulatives...

---

Pourquoi ce message est-il rejeté ? Commentez votre raison. S'il vous plaît, ne votez pas la question si vous ne savez pas ce qu'est le MVP.

Answer 1

Rien ne dit qu'il existe une relation univoque entre un formulaire, une vue et un présentateur. En fait, il est tout à fait raisonnable de diviser les parties d'un formulaire en plusieurs "vues" (je vois cela le plus souvent avec les contrôles utilisateur, mais ce n'est pas obligatoire) et d'avoir un présentateur par vue. Le plus souvent, le formulaire est la vue, mais là encore, ce n'est pas obligatoire.

Comme vous l'avez dit, cela signifie qu'il faut éviter certains monstrueux "tout vu". \all -Ce qui devrait permettre d'obtenir un code plus cohérent et de réduire les problèmes liés aux tests unitaires.

Answer 2

Si je comprends bien, vous travaillez dans une application existante et sur un écran existant. Et ici, vous avez besoin d'ajouter de nouvelles fonctionnalités. Si c'est le cas, l'ajout d'un modèle, d'un présentateur et d'une vue doit déjà être disponible pour cet écran. Si c'est le cas, vous n'avez pas d'autre option que de continuer avec la même architecture, même si vos nouvelles fonctionnalités rendent la vue et le présentateur énormes.

Mais si je me trompe et que vous implémentez l'écran vous-même, alors vous pouvez introduire des contrôles utilisateur avec leur propre modèle, présentateur et vue. Mais veillez à ce que vos contrôles utilisateur soient indépendants les uns des autres, faute de quoi la création d'une passerelle entre les contrôles utilisateur pour communiquer entre eux sera à nouveau source de problèmes et de confusion.

Mais honnêtement, je préfère créer un seul présentateur et une seule vue pour cette tâche, même si les fichiers sont énormes. En général, les contrôles utilisateur sont utilisés pour créer des contrôles communs qui peuvent être utilisés à plusieurs endroits. Avec votre approche, vous risquez d'avoir un problème s'il y a beaucoup de communication entre les contrôles utilisateur que vous créez. Mais oui, cela peut être résolu si les contrôles utilisateurs sont créés avec un bon plan. Mais pour moi, il est préférable d'avoir un seul présentateur et une seule vue, à moins qu'ils ne soient dans une situation de couplage étroit. Et les fichiers volumineux ne devraient pas être un problème si vous avez l'aide de plugins comme resharper.