MVP et granularité du présentateur

Question

Nous utilisons le modèle MVP et Winforms avec un certain succès. Cependant, une question concernant MVP apparaît toujours:

Qu'est-ce qu'une bonne granularité pour les présentateurs?

Ce que je veux dire par là est que: avec Winforms, une granularité fine fonctionne généralement assez bien pour les contrôles utilisateur. De cette façon, il est facile de réutiliser les contrôles utilisateur et de les utiliser comme blocs de construction lors de la conception d'interfaces graphiques plus complexes. Cependant, avoir la même (fine) granularité avec les présentateurs semble être un problème.

D'une part, le fait de disposer de présentateurs à grain grossier empêche d'utiliser le "plug-in". Les commandes et le logiciel violent en quelque sorte le principe DRY: plusieurs présentateurs doivent souvent implémenter la même logique (par exemple, dresser une liste de clients), qui est utilisée par plusieurs commandes plus complexes.

D'autre part, les présentateurs à grain fin semblent limiter la possibilité de réutiliser des contrôles dans différentes situations. Par exemple, une vue d'édition peut parfois avoir besoin de sauver le client immédiatement; il faut parfois le lier à autre chose; il suffit parfois de le valider; etc. Cela dépend souvent du contrôle plus complexe. Mais il y a aussi pas mal de comportements partagés.

Notez que, dans les deux cas, une présentation par 1 présentateur est réalisable. Ce qui est considéré " 1-view " changements.

Quelles sont généralement les meilleures pratiques en matière de granularité de présentation utilisant MVP et Winforms?

• Les présentateurs à grain fin et le comportement personnalisable via des options ou quelque chose de ce genre?
• Présentateurs à grains grossiers et faible possibilité de les utiliser?
• Autre chose?

Clause de non-responsabilité: Nous utilisons principalement le contrôleur de supervision, mais je pense que cela s’applique également à la vue passive. Désolé pour la longue question aussi.

Answer 1

Nous utilisons MVP chez tous nos clients et il s’agit là d’une conversation qui se produit à plusieurs reprises. À quel point notre code derrière les classes et les présentateurs doit-il être propre? Cela dit, nous avons choisi d’utiliser l’approche du présentateur à grains grossiers. Fondamentalement, chaque formulaire aurait son propre présentateur et n'obtiendrait et ne définirait que les propriétés des contrôles d'un formulaire particulier à l'aide de sa vue. Le remplissage des contrôles - un appel à une base de données pour remplir une liste déroulante par exemple - est situé dans une classe de service public. Toute validation des données saisies par l'utilisateur est située dans une classe BO qui peut être réutilisée par n'importe lequel et / ou tous les présentateurs. J'espère que cela aide.

Answer 2

Dans mon système CAD-CAM, mes présentateurs n'utilisent pas les contrôles utilisateur. Les contrôles utilisateur résident dans la vue qui réside dans un assemblage EXE qui implémente les interfaces d'affichage utilisées par le présentateur.

Si vous voulez afficher une liste de clients, je la passe à la vue qui a une liste DisplayCustomerList et utilise la combinaison de commandes utilisateur nécessaire pour afficher la liste de clients. Si plusieurs vues affichent la liste de clients de la même manière, elles partagent un contrôle utilisateur ou une classe dans cet assemblage ExE / View. Cette classe ne sort pas de cette assemblée.

Notre logiciel est adapté à l’exécution de nombreux types de découpeuses. Nous mettons donc beaucoup d'emphase sur la possibilité d'extraire l'interface utilisateur et de la remplacer par une interface utilisateur complètement différente (correspondant à une machine différente). Toutes ces interfaces utilisateur font référence au même ensemble d'assemblages principaux.

La hiérarchie ressemble à ceci

Voir EXE Mise en œuvre du présentateur Command Assembly - les commandes sont exécutées par le présentateur qui modifie le modèle. Interfaces du présentateur Assemblages de modèles

Les assemblages chargeables définissent un contenu dynamique, tels que les types de fichiers pouvant être chargés, les rapports, les pilotes de périphérique de découpe, etc. Ils implémentent diverses interfaces présentes dans les assemblys de modèles

.

Une des choses que je fais est que je n’impose pas un présentateur de vue pour chaque dialogue. Si la boîte de dialogue est étroitement liée à une commande, elle est définie, créée et utilisée aux côtés de la classe de commande. Parfois, un groupe de commandes liées partagera une boîte de dialogue (Gestion de fichier par exemple).

La question essentielle que je pose lors de l'utilisation de MVP est la suivante: "Que se passe-t-il si vous souhaitez remplacer complètement les formulaires par quelque chose d'autre?". Les réponses à cette question identifieront les cas dans lesquels vous êtes trop dépendant d'un contrôle utilisateur ou d'un moteur de formulaire particulier.

Le plus gros problème de ma configuration (et de celui pour lequel je n’ai pas de bonne réponse) est que les IDE et les langages actuels facilitent très facilement l’association des contrôles utilisateur aux enregistrements de la base de données. Il est si productif comparé à toute autre configuration, il a tendance à dominer la conception. Je n'ai pas eu beaucoup à faire avec ce problème dans mon application de CAO-FAO, je n'ai donc pas d'autre solution que de passer l'ensemble de données à la vue et de le laisser le gérer. Ce site contient des modèles qui peuvent être utiles dans cette situation.