Quelle est la bonne pratique pour diviser les présentateurs dans un modèle d'interface MVP devenu trop grand?

Question

Un problème que je rencontre fréquemment ces derniers temps est le problème de la taille excessive de mes classes de présentateurs. Habituellement, je peux couper une grande classe régulière sans perdre un battement. Mais les présentateurs sont parfois un peu plus difficiles à réduire, sans rendre le code plus difficile à suivre.

En particulier lorsque la page commence à se remplir avec les commandes orientées CRUD. Parfois, je divise les contrôles, mais s’ils sont affectés par d’autres contrôles, la logique de coordination est complexe en soi. Parfois, je divise la récupération des données sous forme de liste ou de grille, mais cela peut parfois avoir des pièges similaires.

Existe-t-il des techniques, des règles empiriques ou des zones communes que vous refactoriez sur vos présentateurs?

Answer 1

J'utilise généralement deux approches:

1. Extraire et déléguer des règles métier aux classes de domaine.
2. Partitionnez la vue en contrôles liés de manière logique, puis créez une nouvelle interface de vue pour chaque partition. Vous pouvez ensuite diviser votre présentateur dans le même sens. Si la plate-forme que vous utilisez prend en charge les groupes de composants de sous-formulaire (contrôles utilisateur C #, cadres Delphi, etc.), il s'agit d'un moyen puissant de création de contrôles réutilisables.

Mettre à jour

Lors du fractionnement des vues, je commence généralement par fractionner l'interface et par le fait que mon formulaire implémente plusieurs interfaces.

public class ComplexForm: Form, ISubView, IOtherSubView
{
    ...
}

Ensuite, j'ai divisé le présentateur en autant de vues que j'ai créées.

public class SubViewPresenter
{
    private ISubView subView;
    ...
}

public class OtherSubViewPresenter
{
    private IOtherSubView otherSubView;
    ...
}

Vous pouvez aller plus loin et déplacer l'implémentation de ISubView et IOtherSubView vers les contrôles utilisateur ou les laisser tels quels. Si vous utilisez un modèle vue passive , il s'agit d'un jeu d'enfant, car le formulaire ne gère de toute façon que la logique de l'interface utilisateur. Une fois que je sépare le présentateur, j'essaie d'éviter les communications directes entre les présentateurs. Si une communication est nécessaire, j'essaie de le faire indirectement à travers des objets de domaine.

Answer 2

Essayez d’extraire le code qui exécute une activité en dehors de la transmission de données à votre DAL ou de sa transmission à la vue. Par exemple, si vous devez effectuer des mises à jour par courrier électronique ou appliquer une logique métier, essayez de les extraire dans des classes distinctes. Je traite souvent le même problème et essaie de déplacer autant de logique que possible vers les classes de domaine / entité individuelles et d’y effectuer une validation.

J'espère que cela vous sera utile.