Il semble que vous soyez tombé dans certains des pièges courants, mais ne vous inquiétez pas, ils peuvent être corrigés :)
Vous devez d'abord regarder votre application un peu différemment et commencer à la décomposer en morceaux. Nous pouvons diviser les morceaux dans deux directions. Tout d'abord, nous pouvons séparer la logique de contrôle (les règles métier, le code d'accès aux données, le code des droits utilisateur, tout ce genre de choses) du code de l'interface utilisateur. Deuxièmement, nous pouvons décomposer le code de l'interface utilisateur en morceaux.
Nous ferons donc la dernière partie en premier, en décomposant l'interface utilisateur en morceaux. La façon la plus simple de le faire est d'avoir un seul formulaire hôte sur lequel vous composez votre interface utilisateur avec des commandes utilisateur. Chaque contrôle utilisateur sera en charge d'une région du formulaire. Imaginez donc que votre application contienne une liste d'utilisateurs, et lorsque vous cliquez sur un utilisateur, une zone de texte en dessous est remplie avec ses détails. Vous pouvez avoir un contrôle utilisateur gérant l'affichage de la liste des utilisateurs et un second contrôlant l'affichage des détails de l'utilisateur.
Le vrai truc ici est de savoir comment gérer la communication entre les commandes. Vous ne voulez pas que 30 contrôles utilisateur sur le formulaire contiennent tous des références les uns aux autres et appellent des méthodes dessus.
Vous créez donc une interface pour chaque contrôle. L'interface contient les opérations que le contrôle accepte et tous les événements qu'il déclenche. Lorsque vous pensez à cette application, vous ne vous souciez pas si la sélection de liste de zone de liste change, vous êtes intéressé par le fait qu'un nouvel utilisateur a changé.
Donc, en utilisant notre exemple d'application, la première interface pour le contrôle hébergeant la liste des utilisateurs inclurait un événement appelé UserChanged qui passe un objet utilisateur.
C'est génial parce que maintenant, si vous vous ennuyez de la liste et que vous voulez un contrôle de l'œil magique zoomy 3d, il vous suffit de le coder sur la même interface et de le brancher :)
Ok, donc la deuxième partie, séparant la logique de l'interface utilisateur de la logique du domaine. Eh bien, c'est un chemin bien usé et je vous recommande de regarder le modèle MVP ici. C'est vraiment simple.
Chaque contrôle est maintenant appelé une vue (V dans MVP) et nous avons déjà couvert la plupart de ce qui est nécessaire ci-dessus. Dans ce cas, le contrôle et une interface pour cela.
Tout ce que nous ajoutons, c'est le modèle et le présentateur.
Le modèle contient la logique qui gère l'état de votre application. Vous savez, il irait à la base de données pour obtenir les utilisateurs, écrire dans la base de données lorsque vous ajoutez un utilisateur, etc. L'idée est que vous pouvez tester tout cela en toute isolation de tout le reste.
Le présentateur est un peu plus difficile à expliquer. C'est une classe qui se situe entre le modèle et la vue. Il est créé par la vue et la vue se transmet au présentateur à l'aide de l'interface dont nous avons parlé précédemment.
Le présentateur n'a pas besoin d'avoir sa propre interface, mais j'aime quand même en créer une. Rend explicite ce que vous voulez que le présentateur fasse.
Ainsi, le présentateur exposerait des méthodes telles que ListOfAllUsers que la vue utiliserait pour obtenir sa liste d'utilisateurs, sinon, vous pourriez mettre une méthode AddUser la vue et l'appeler à partir du présentateur. Je préfère ce dernier. De cette façon, le présentateur peut ajouter un utilisateur à la liste quand il le souhaite.
Le présentateur aurait également des propriétés comme CanEditUser, qui retourneront true si l'utilisateur sélectionné peut être modifié. La vue interroge ensuite chaque fois qu'elle a besoin de savoir. Vous voudrez peut-être des éditables en noir et en lecture seule en gris. Techniquement, c'est une décision pour la vue car elle est axée sur l'interface utilisateur, si l'utilisateur est modifiable en premier lieu, c'est pour le présentateur. Le présentateur le sait parce qu'il parle au modèle.
Donc, en résumé, utilisez MVP. Microsoft fournit quelque chose appelé SCSF (Smart Client Software Factory) qui utilise MVP de la manière que j'ai décrite. Il fait aussi beaucoup d'autres choses. C'est assez complexe et je n'aime pas la façon dont ils font tout, mais cela peut aider.