Etre ou ne pas être avec des modèles en double

Question

Dans ma nouvelle mission, j'ai hérité de ce morceau hérité, que j'ai dû refaire et refactoriser. La portée était initialement limitée au niveau Présentation, qui était le plus volumineux. Au cours de l'analyse, il a été réalisé que l'application a été construite sur une période de temps avec différents modules utilisant différentes classes pour représenter le même modèle.

Ces modèles sont en fait utilisés pour lier des informations à la fois en vue et en db tier (Code réutiliser quelqu'un?). La logique de liaison est une routine complexe et a été stabilisée après plusieurs tests. Maintenant, j'ai ce dilemme de savoir s'il faut conserver ces modèles sémantiquement dupliqués mais syntaxiquement incompatibles ou de commencer par une table rase. La deuxième option signifierait réorganiser l'ensemble de l'application et les horaires ne permettent pas cela, mais j'ai une mauvaise idée. Pouvez-vous les gars partagent quelques pensées intérieures (avantages & par contre) et tous les problèmes imprévus que je pourrais avoir à l'avenir.

Donner l'analogie suivante qui reflète étroitement l'état des choses. Pour commencer, il y a un module de détails de l'utilisateur, qui ressemble plus à un getter. La vue est rendue en utilisant la structure TO (objet de transfert) prévue à cet effet. Dites 'Class UserInfo'

Plus tard, une nouvelle exigence est apparue et une disposition pour éditer les détails a été fournie. Celui qui l'a codé a décidé d'utiliser une nouvelle structure TO et a créé son propre 'Class UserEditInfo'. Ce qui est une sorte de super ensemble de classe plus tôt.

Enfin, à un moment différent, une nouvelle amélioration pour suivre les transactions de l'utilisateur a été faite et devinez quoi, un nouveau 'Class UserDetails' a été créé. Tout ce qui précède a des liaisons qui les mappent à la logique tierce et JSP, en essayant d'éliminer deux des modèles provoquerait des répétitions dans le niveau entier de l'entreprise (ce qui est mauvais). Pour empirer les choses, les bons vieux cow-boys ne sont plus là pour nous aider. Espérons que cela aide

Answer 1

Ok, comme vous l'avez mentionné, vous ne pouvez pas commencer frais alors oublions cette idée. Ce que j'aime faire, c'est de trouver du code qui fasse la même chose (comme les modules de liaisons) et de leur faire implémenter une nouvelle interface de votre propre design. Comme IDataBindingsModule, cette interface a des méthodes communes que les deux modules "font" (comme vous le dites) la même chose.

Ensuite, retirer toutes les instances des types de béton et d'utiliser la nouvelle interface IDataBindingsModule à la place, puis une fois que vous avez fait cela et fait en sorte que rien n'a cassé, son tout simplement une question de remplacer les implémentations de votre nouvelle interface IDataBindingsModule avec une implémentation unifiée.

Cette approche ne fonctionne que si les multiples modules comme ils le font maintenant font la même chose, sinon cela ne marchera pas très bien.

J'espère que c'est sur la bonne voie quant à ce que vous demandiez, désolé si je vous ai mal compris.

Answer 2

Il n'y a pas beaucoup de valeur à réécrire le tout simplement parce que l'architecture n'est pas idéale. Comme vous l'avez noté, ce sera très coûteux. Une approche consisterait à choisir la meilleure mise en œuvre des modèles et à concentrer les développements ultérieurs dans ce modèle.

Si vous devez développer une fonctionnalité de l'un des autres modèles, vous pouvez migrer l'implémentation de la fonctionnalité existante du modèle hérité vers le modèle principal que vous avez choisi et l'étendre au besoin.

Answer 3

En supposant que vous ayez un mappage 1 à 1 des classes dans les deux modèles, vous pouvez essayer de les fusionner.

Vous pouvez le faire en prenant comme base l'une des classes correspondantes et en hériter l'autre classe et d'une interface extraite. La prochaine chose est de déplacer toute votre logique de cartographie à l'intérieur de la classe (idéalement à l'intérieur des accesseurs de propriété). Le nouveau modèle sera toujours utilisé à travers les anciens types d'interface, juste la mise en œuvre concrète sera la même.

Cela vous permettra de lancer le même objet entre l'ancienne et la nouvelle représentation. Graduellement, vous pouvez rechercher les utilisations des méthodes non désirées et les supprimer. Cela prendra beaucoup de temps, mais est moins risqué que déchirer et remplacer.

Answer 4

Comme l'indique Mark, vous pouvez implémenter le modèle Adapter pour créer une interface unique vers les modèles d'objets disparates. Cela permet de présenter une interface unifiée à la couche de présentation de l'application tout en préservant ce que vous travaillez sur le back-end.

Avec le temps, vous pouvez ensuite refactoriser les pièces que vous voulez modifier tout en étant capable de tester vos résultats par rapport à l'application de la fonction.