C #: comment concevoir intelligemment une interface graphique pour une application de bureau avec l'encapsulation à l'esprit

Question

Je développe une application de bureau avec un MainForm qui est devenu assez volumineux. Il existe de nombreux contrôles dans plusieurs conteneurs à différents niveaux (SplitContainers, TabPages, Panels).

Maintenant, je veux refactoriser cette classe en séparant tout le code du contrôleur responsable de la liaison de données & amp; effacer les contrôles ou effectuer des interactions utilisateur dans des classes de contrôleurs distinctes.

[MODIFIER]

Objet

Le but de cette application est de suivre les commandes (appelées Job) et leurs positions (appelées Jobitem). Chaque tâche est liée à un client, chaque tâche à un article (les tâches contiennent des informations spécifiques au processus de fabrication de son article, par conséquent, elles enveloppent l'article). Job, Jobitem, Customer et Article ont des propriétés dynamiques (paires clé / valeur) qui sont gérées par une classe PropertyManager.

Architecture

Mon application est divisée en 2 projets principaux: Le noyau contient le modèle de données dans 3 classes de DataContext LinqToSQL:

• ArticleManagement
• JobManagement
• PropertyManagement

Pour chaque classe DataContext, il existe une classe XyzManager qui fournit l'objet LinqToSQL d'une collection à l'interface graphique, encapsulant la source de données LinqToSQL. Il gère également la création, la suppression et la modification des types DataContext correspondants.

Ensuite, j'ai un projet d'interface graphique, contenant naturellement un formulaire principal et quelques formulaires supplémentaires pour des éléments tels que des options, etc. À partir de maintenant, mon projet d'interface graphique contient une référence à chaque classe XyzManager et obtient & amp; définit les données via les classes du gestionnaire en fonction des interactions de l'utilisateur, contenant toute la logique de contrôle.

J'ai mis l'essentiel de la logique indépendante pour cela dans une classe d'utilitaires statique en dehors de la classe de formulaire principale, mais je suppose que c'est une approche moins qu'idéale.

[/ EDIT]

Il s’agit de ma première application de bureau plus grande et j’ai du mal à encapsuler l’interface graphique. À l'heure actuelle, tout le code du contrôleur responsable de la gestion des interactions utilisateur réside dans la classe MainForm.

Je connais le modèle MVC, mais je ne sais pas comment l'appliquer sur un fichier WinForm C # avec ma conception actuelle.

Mon code personnalisé à lui seul a une longueur de plus de 2 400 lignes, sans compter le code généré automatiquement du formulaire, avec une tendance à la hausse. Je veux reformuler ceci, mais je ne sais pas comment résoudre ce problème de manière plus élégante.

Answer 1

Pour les applications à petite échelle, vous devriez jeter un oeil à Model-View-Presenter (MVP), il y a une bonne présentation de la meilleure façon (à mon avis) de faire MVP: http://martinfowler.com/eaaDev/SupervisingPresenter.html

Answer 2

Normalement, j'essaie de composer une interface graphique complexe en utilisant des UserControls plus petits. Mais quelques points sont très importants:

• Chacun de ces contrôles utilisateur doit être indépendant (en particulier du formulaire)
• Les contrôles utilisateur ayant le droit d’afficher ou de modifier certaines données ne doivent dépendre que de ces données. Vous devez essayer d’implémenter vos contrôles de manière à ce qu’ils puissent être liés à un DataSource couvrant toutes les données dont le contrôle a besoin.
• Lorsque vous devez transmettre des informations au conteneur parent (un autre UserControl ou le formulaire), utilisez les événements auxquels le conteneur peut s'abonner.
• Lorsque vous utilisez des menus (contextuels), vérifiez s'ils sont liés à certains éléments. Vous devez créer les menus à proximité des éléments et non dans UserControls. Ainsi, lorsque vous affichez plusieurs fois le même élément sur l'interface graphique dans plusieurs vues (contrôles), chaque élément doit avoir le même menu contextuel.
• Essayez d'appliquer un modèle de commande pour les actions des boutons / menus.

Vos solutions semblent ne pas séparer les différentes responsabilités jusqu’à présent. Diviser le code en différents contrôles sans définir clairement les frontières et les responsabilités ne suffit pas.

Answer 3

Consultez le Bloc d'application d'interface utilisateur composite .

Answer 4

Utilisez-vous JobController uniquement pour un seul formulaire? Dans l'affirmative, il vous suffira peut-être de scinder le code caché en plusieurs fichiers à l'aide de mot clé partiel ?