Comment faire face aux actions monstrueuses de Struts?

Question

J'ai hérité de cette gigantesque application Web Java héritée avec Struts 1.2.4. J'ai une question spécifique concernant les actions. La plupart des pages ont exactement une action et les méthodes processExecute () sont des monstres hideux (très longues et énormément d'instructions if imbriquées basées sur des paramètres de requête).

Étant donné que les actions sont une implémentation du modèle de commande, je pense à scinder ces actions en une seule action par geste de l'utilisateur. Ce sera un grand refactoring cependant, et je me demande:

1. Est-ce la bonne direction?
2. Existe-t-il une étape intermédiaire que je pourrais franchir, une structure qui traite du désordre à l’intérieur des actions monolithiques? Peut-être un autre motif de commande à l'intérieur de l'action?

Answer 1

Ma façon de gérer cela serait:

• ne faites pas 'tout à la fois'
• chaque fois que vous changez quelque chose, laissez-le mieux que vous ne l'avez trouvé
  • le remplacement des conditions par des implémentations d'action distinctes est une étape.
  • Mieux encore: séparez vos implémentations des classes Action pour pouvoir les utiliser lorsque vous modifiez des infrastructures
  • Conservez votre nouvelle implémentation de commande absolument sans références à Struts, utilisez vos nouvelles actions comme wrapper autour de ces implémentations.
  • Vous devrez peut-être fournir des interfaces à vos ActionForms Struts afin de les transmettre sans copier toutes les données. D'autre part, vous voudrez peut-être transmettre d'autres objets qu'ActionForm qui sont généralement un groupe de chaînes (consultez votre autre question sur ActionForms Struts 1.2 )
• commencez la migration des pièces vers les nouvelles & amp; meilleure technologie. Struts 1.2 était génial quand il est sorti, mais ce n’est certainement pas ce que vous voulez soutenir dans l’éternité. Il existe maintenant plusieurs générations de meilleurs cadres.

Il y en a bien plus - Désolé, je manque de temps ici ...

Answer 2

Struts Actions, dans mon esprit, ne devraient pas contenir beaucoup de code. Ils doivent juste interagir directement avec la demande et la réponse - prendre certaines données d'un formulaire ou d'un paramètre de demande, transmettre ces informations à la couche de service, puis placer des éléments dans un objet Response ou éventuellement enregistrer certaines données dans la session de l'utilisateur.

Je vous conseillerais de ne pas faire d'héritage avec des classes d'action. Cela semble être une bonne idée au début, mais je pense que tôt ou tard, vous réaliserez que vous êtes encore plus séduisant que de rendre la base de code robuste. Struts a suffisamment d'actions de base en l'état. Si vous en créez de nouvelles, vous avez probablement du code dans la couche Web qui ne devrait pas être là.

Ce n’est que mon expérience personnelle.

Answer 3

J'ai déjà eu affaire à ce genre de chose. Une bonne première étape consiste à insérer une autre classe de base dans la chaîne d'héritage entre Action et l'une des classes d'actions monstrueuses d'origine (appelons-la ClassA). Surtout si vous n'avez pas le temps de tout faire en même temps. Ensuite, vous pouvez commencer à extraire des fonctionnalités dans des classes d’action parallèles plus petites (ClassB, ClassC). Tout ce qui est commun entre la classe d'origine et les nouvelles classes refactorisées peut être récupéré dans la nouvelle classe de base. Donc, la hiérarchie ressemble maintenant à ceci:

Original Hierarchy:      New Hierarchy:

     Action                   Action
       |                        |
       |                      BaseA
  (old)ClassA                   |
                       +--------+----------+
                       |        |          |
                   ClassB (new)ClassA   ClassC

Answer 4

1. Passez d'une méthode à la fois
2. Enregistrez des cas de test que vous pourrez lire plus tard. Exemple ici (assurez-vous de sélectionner le plus de chemins possible dans le code, c'est-à-dire que tous les gestes de l'utilisateur sur la page qui appellent cette action)
3. refactorisez la méthode pour en réduire la complexité en créant des méthodes plus petites réalisant des tâches plus petites.
4. Relancez les tests en même temps

À ce stade, vous avez refactorisé la version de la méthode Big Big ennuyante. Vous pouvez maintenant créer des actions spécifiques .

Vous pouvez utiliser votre classe refactorisée récemment comme classe de base et implémenter chaque action spécifique en tant que sous-classe à l'aide de ces petites méthodes refactorisées.

Une fois que vous avez terminé, vous devez avoir une bonne idée de la logique partagée entre les classes et pouvoir afficher ou appliquer ces méthodes au besoin.

Ce n'est pas amusant, mais si vous travaillez sur la base de code pendant un moment, vous gagnerez du temps et des maux de tête.

Answer 5

Problème difficile mais typique des premiers développements d'applications web.

Tout d’abord, vous devez commencer par réfléchir à la logique qui constitue le comportement des entreprises, à la logique qui constitue le "flux". (c’est-à-dire ce que l’utilisateur voit) et quelle logique obtient le contenu correspondant à ce qu’il voit.

Vous n'êtes pas obligé de choisir des usines, des interfaces, etc. L’implémentation rétroactive est bien moins utile… mais consolider la logique métier et la logique d’extraction des données en délégués de quelque sorte que ce soit… et laisser les actions struts déterminer le flux de pages en fonction du succès / échec de cette logique.

À partir de là, il vous suffit de prendre quelques semaines et de le broyer

Answer 6

Une méthode longue n’est jamais bonne, sauf s’il s’agit d’une instruction switch unique où les cas sont très courts (analyse de jetons ou quelque chose comme ça).

Vous pouvez au moins reformuler la méthode longue en méthodes plus petites avec des noms descriptifs.

Si possible, vous pourriez commencer votre méthode en reconnaissant ce qu’elle devrait faire en examinant le formulaire, puis en vous dirigeant vers les différentes options. Pas de si imbriqué cependant, ceux-ci ont tendance à rendre le code illisible. Juste

enum Operation {
  ADD, DELETE;
}

...

Operation operation = determineOperation(form);
if (operation == Operation.DELETE) { 
  doDelete(form); 
} else if (operation == Operation.ADD) {
  doAdd(form);
}

Si vous pouvez aller aussi loin, votre logique est claire et nette et vous pouvez refactoriser à votre guise.

La difficulté consiste à clarifier votre logique et vous pouvez le faire par étapes. Ne choisissez pas un modèle avant d’avoir compris en quoi consiste exactement votre problème.

Answer 7

Si vous envisagez de refactoriser le code, veillez à bien écrire les tests du code existant afin de vous assurer que vous n'en avez pas modifié les fonctionnalités une fois que vous avez commencé le refactoring.