Exemple de problème transversal
Quel est un bon exemple de cross-cutting concern? L’exemple de dossier médical de la page wikipedia me semble incomplet.
Particulièrement dans cet exemple, pourquoi la journalisation conduirait-elle à une duplication de code (diffusion () )? (Outre des appels simples tels que log("....") partout, ce qui ne semble pas être un gros problème).
Quelle est la différence entre un core concern Et un cross-cutting concern?
Mon objectif final est d’avoir une meilleure compréhension de l’AOP.
Avant de comprendre l'inquiétude transversale , nous devons comprendre l'inquiétude .
Un Préoccupation est un terme qui fait référence à une partie du système divisée en fonction de la fonctionnalité.
Les préoccupations sont de deux types:
- Les problèmes représentant une fonctionnalité unique et spécifique pour les exigences principales sont appelés problèmes principaux .
OU
Les principales fonctions du système sont connues.
Par exemple : logique applicative - Les préoccupations représentant des fonctionnalités pour des exigences secondaires sont appelées préoccupations transversales ou préoccupations à l'échelle du système .
OU
La préoccupation transversale est une préoccupation qui s'applique à l’ensemble de l’application et qui affecte l’ensemble de celle-ci.
Par exemple: la journalisation, la sécurité et le transfert de données sont les préoccupations qui sont nécessaires dans presque tous les modules d'une application. préoccupations de coupe.
Cette figure représente une application typique divisée en modules. La principale préoccupation de chaque module est de fournir des services pour son domaine particulier. Cependant, chacun de ces modules requiert également des fonctionnalités auxiliaires similaires, telles que la journalisation de la sécurité et la gestion des transactions. La journalisation est un exemple de problème transversal fréquemment utilisé dans les applications distribuées pour faciliter le débogage en traçant les appels de méthodes. Supposons que nous enregistrions au début et à la fin de chaque corps de fonction. Cela entraînera une coupe transversale de toutes les classes ayant au moins une fonction.
Je pense que le comportement transactionnel est le meilleur exemple d'une préoccupation intersectorielle. Par exemple, devoir mettre des blocs try-catch avec des appels de validation et d'annulation dans toutes vos méthodes de service serait répulsif. L'annotation des méthodes avec un marqueur pouvant être utilisé par AOP pour les encapsuler avec le comportement transactionnel souhaité est un gain important.
L'autorisation est un autre bon candidat comme exemple de préoccupation transversale. Annoter une méthode de service avec un marqueur indiquant qui peut l'appeler et laisser un conseil AOP décider d'autoriser ou non l'appel de la méthode peut être préférable à la gestion de ce code de méthode en service.
L'implémentation de la journalisation avec les conseils AOP pourrait être un moyen d'obtenir plus de flexibilité, de sorte que vous puissiez changer ce qui est journalisé en changeant un point de jonction. En pratique, je ne vois pas les projets le faire très souvent. L'utilisation d'une bibliothèque telle que log4j, qui vous permet de filtrer par niveau de journalisation et par catégorie, au moment de l'exécution, fonctionne si bien.
Une préoccupation essentielle est la raison pour laquelle l'application existe, à savoir la logique métier qu'elle automatise. Si vous avez une application logistique qui gère le fret, déterminer la quantité de fret que vous pouvez emballer dans un camion ou le meilleur itinéraire à suivre pour faire ses livraisons peut être une préoccupation essentielle. Les problèmes transversaux sont généralement des détails de mise en œuvre qui doivent être séparés de la logique métier.
En plus de la réponse acceptée, je souhaite mentionner un autre exemple de problème transversal: la communication à distance. Supposons que je veuille simplement appeler d'autres composants de mon écosystème localement, comme s'ils étaient en cours d'exécution. Peut-être que dans certains cas, ils le font même. Mais maintenant, je veux exécuter mes services distribués dans un nuage ou un cluster. Pourquoi devrais-je me préoccuper de cet aspect en tant que développeur d'applications? Un aspect pourrait s’occuper de savoir qui appeler et comment et comment, sérialiser les données transmises si nécessaire et faire un appel à distance. Si tout était en cours, l'aspect ne ferait que transférer l'appel local. Du côté de l'appelé, l'aspect désérialiserait les données, passerait l'appel local et renverrait le résultat.
Permettez-moi maintenant de vous raconter une petite histoire sur des choses "triviales" telles que la sortie du journal: Il y a quelques semaines à peine, j'ai refactoré une base de code complexe, mais pas trop grande (environ 250 000 lignes de code) pour un client. Dans quelques centaines de classes, un type de cadre de journalisation a été utilisé, dans quelques centaines d’autres. Ensuite, il y avait plusieurs milliers de lignes de System.out.println(*) où il aurait vraiment dû y avoir une sortie de journal. J'ai donc fini par réparer des milliers de lignes de code dispersées dans la base de code. Heureusement, je pouvais utiliser quelques astuces intelligentes dans IntelliJ IDEA (recherche structurelle et remplacement)) afin d'accélérer toute l'action, mais ne pensez-vous pas que c'était trivial! Bien sûr, fortement dans le contexte- la journalisation de débogage dépendante aura toujours lieu dans le corps d'une méthode, mais de nombreux types de journalisation importants tels que les appels de méthode de traçage (même hiérarchiquement avec une sortie bien indentée), la consignation des exceptions gérées ou non gérées, l'audit utilisateur (la consignation d'appels avec des méthodes restreintes basées sur l'utilisateur) Les rôles etc.) peuvent facilement être implémentés dans des aspects sans pour autant polluer le code source. Le développeur d’applications au quotidien n’a pas besoin de réfléchir ni même de voir les appels de l'enregistreur dispersés dans la base de code. date et peut même basculer la stratégie de journalisation ou l'ensemble de la structure de journalisation de manière centralisée et centralisée.
Je peux proposer des explications similaires pour d’autres préoccupations transversales. Garder le code propre et à l'abri de toute dispersion et de tout enchevêtrement L'OMI est une question de professionnalisme, pas une option. Enfin, il conserve le code lisible, maintenable, refactorable. Amen.