La meilleure façon de gérer la confusion entre le code commercial et le code de présentation ?

Question

Considérons une situation hypothétique dans laquelle une ancienne bibliothèque de présentations héritée a été maintenue au fil des ans et a progressivement intégré de plus en plus de logique métier grâce à un processus de corrections hâtives et à un manque de surveillance architecturale appropriée.Vous pouvez également considérer une classe métier ou un espace de noms qui n'est pas séparé de la présentation par les limites de l'assembly et qui est donc capable de référencer quelque chose comme System.Windows.Forms sans être obligé d'ajouter une référence (une action beaucoup plus sobre qu'une simple clause using) .

Dans des situations comme celle-ci, il n'est pas inimaginable que le code métier utilisé par ce code d'interface utilisateur soit éventuellement sollicité pour être réutilisé.Quelle est la bonne façon de refactoriser les deux couches séparément pour permettre cela ?

Je suis vaguement familier avec les modèles de conception – du moins en principe en tout cas.Cependant, je n'ai pas beaucoup d'expérience pratique et je ne suis donc pas sûr de mes intuitions.J'ai commencé à utiliser le modèle de stratégie pour cela.L'idée est d'identifier les endroits où la logique métier appelle les composants de l'interface utilisateur pour poser une question à l'utilisateur et collecter des données, puis de les encapsuler dans un ensemble d'interfaces.Chaque méthode de cette interface contiendra le code orienté UI du flux de travail d'origine, et la classe UI implémentera ensuite cette interface.

Le nouveau code qui souhaite réutiliser la logique métier en question implémentera également cette interface, mais en substituant soit de nouvelles fenêtres, soit éventuellement des réponses préfabriquées ou paramétrées aux questions auxquelles répondaient initialement les composants de l'interface utilisateur.De cette façon, la logique biz peut être traitée comme une véritable bibliothèque, bien qu'avec un paramètre d'interface quelque peu gênant transmis à certaines de ses méthodes.

Est-ce une approche décente ?Comment devrais-je mieux procéder ?Je m'en remets à votre sagesse collective sur Internet.

Merci!

Answer 1

Vous semblez prendre une bonne approche, dans laquelle vous cassez les dépendances entre les éléments en béton dans votre conception à la place dépendra des abstractions (interfaces). Lorsque vous rompez les dépendances comme ça, vous devez immédiatement commencer à utiliser des tests unitaires pour couvrir votre base de code existant et de faire évoluer la conception avec une assurance améliorée.

Je l'ai trouvé le livre Travailler efficacement avec Legacy code d'une valeur inestimable dans ces situations. En outre, ne pas sauter à droite dans les modèles sans regarder d'abord les principes de conception orientée objet, comme le SOLIDES principes . Ils guident souvent votre choix des modèles et des décisions sur l'évolution du système.

Answer 2

Je suggère humblement Model-View -Controller - MVC a une forte probabilité comme une solution réussie à votre problème. Il sépare diverses logiques, comme vous le décrivez.

HTH

Answer 3

J'aborderais cela en identifiant clairement les entités et les actions qu'elles peuvent faire ou peuvent leur être faites.Ensuite, un par un, essayez de commencer à créer des objets de logique métier indépendants pour ceux qui refactorisent la logique hors de l'interface utilisateur, en appelant l'interface utilisateur aux objets BL.

À ce stade, si je comprends bien votre scénario, vous auriez une main pleine d'objets BL, dont une partie effectuait des appels de formulaires gagnants, les appels de formulaires gagnants devraient être promus dans la couche d'interface utilisateur.

Ensuite, comme le dit JustBoo, ​​je pense que vous aurez une situation suffisamment distincte pour commencer à extraire les contrôleurs de votre BL et de votre interface utilisateur et que tout cela fonctionne dans une conception MVC.

Answer 4

D'accord, compte tenu de vos différents commentaires, je prendrais l'avis de M. Hoffa et l'étendre. Je suis sûr que vous avez entendu des problèmes difficiles devraient être divisés en unités toujours plus petites de travail jusqu'à ce qu'ils puissent être « conquises ».

En utilisant cette technique, couplée avec les méthodes de Refonte pourrait résoudre vos problèmes. Il y a un livre et beaucoup d'informations sur le web à ce sujet. Vous avez maintenant un lien. Cette page a une tonne de liens vers des informations.

Un autre lien de la auteur du livre.

Alors, vous refactoring, lentement mais sûrement à la bonté crémeuse de MVC, étape par étape.

HTH