Transversales qui concernent exemple

Ce qui est un bon exemple d'un cross-cutting concern? Le dossier médical exemple sur le wikipédia page semble incomplète pour moi.

Plus précisément à partir de cet exemple, pourquoi la journalisation conduire à la duplication de code (diffusion)? (Outre les simples appels tels que log("....") partout, ce qui ne semble pas être une grosse affaire).

Quelle est la différence entre un core concern et un cross-cutting concern?

Mon objectif final est d'obtenir une meilleure compréhension de l'AOP.

InformationsquelleAutor jlars62 | 2014-05-16
  1. 205

    Avant de comprendre l' Transversaux Concernent, nous devons comprendre la Préoccupation.

    Un Préoccupation est un terme qui se réfère à une partie du système répartis sur la base de la fonctionnalité.

    Préoccupations sont de deux types:

    1. Les préoccupations représentant unique et des fonctionnalités spécifiques pour les exigences primaires sont connus comme cœur des préoccupations.

      OU

      Primaire functionlity du système est sait que le cœur des préoccupations.

      Par exemple: la logique d'Entreprise
    2. Les préoccupations représentant fonctionnalités pour les besoins secondaires sont appelés problèmes intersectoriels ou à l'échelle du système des préoccupations.

      OU

      Le transversaux concernent est une préoccupation qui est applicable à l'ensemble de l'application et il affecte l'ensemble de l'application.

      Par exemple: de journalisation, de sécurité et de transfert de données sont les préoccupations qui sont nécessaires dans presque chaque module d'une application, d'où ils sont transversaux préoccupations.

    Courtoisie

    Transversales qui concernent exemple

    Cette figure représente un exemple typique d'application, qui est décomposé en modules. Chaque module est la préoccupation principale est de fournir des services de son domaine particulier. Cependant, chacun de ces modules nécessite également similaire auxiliaires fonctionnalités, telles que la journalisation de la sécurité et de la gestion des transactions. Un exemple de problèmes intersectoriels est la "journalisation", qui est fréquemment utilisé dans les applications distribuées à l'aide de débogage en traçant les appels de méthode. Supposons que nous faisons de l'enregistrement à la fois le début et la fin de chaque corps de la fonction. Il en résultera transversale à toutes les classes qui ont au moins une fonction.

    (Avec l'aimable autorisation)

    • "Le façonnage souci est un souci qui est applicable à l'ensemble de l'application" ➤ Pas sûr de ce depuis la gestion des transactions n'est pas applicable "à travers" l'application mais c'est toujours une préoccupation horizontale. Et l'image ne me dit rien, pour être honnête, c'est seulement à confusion..
    • Bonne explication, mais j'ai un peu d'un problème avec l'image où nous appelons ces préoccupations transversales pas de coupe-ed préoccupations et il serait mieux je pense pour couper d'autres préoccupations transversales préoccupations, et non pas d'une autre manière autour. Comme l'Aspect-oriented development
    • encore la réponse ne précise pas le problème tout simplement en utilisant quelque chose comme Log4j et de journalisation comme LogManager.getLogger().info(ModuleName, msg)
    InformationsquelleAutor Premraj
  2. 41

    Je pense que le meilleur exemple d'une transversale préoccupation est transactionnelle comportement. Avoir à mettre les blocs try-catch avec commit et rollback appels dans toutes vos méthodes de service serait un anti-moustique, par exemple. L'annotation de l'méthodes avec un marqueur qui AOP pouvez utiliser pour encapsuler avec l'souhaité transactionnelle comportement est une grande victoire.

    Un autre bon candidat comme un exemple de la manière transversale l'inquiétude est d'autorisation. L'annotation d'une méthode de service avec un marqueur qui indique qui peut l'appeler et laisser certains AOP conseils décider d'autoriser l'appel de méthode ou pas, peut être préférable à la manipulation que dans le service, le code de la méthode.

    La mise en œuvre de l'enregistrement à l'aide de l'AOP de conseil pourrait être une façon d'obtenir plus de flexibilité, de sorte que vous pouvez changer ce qui est enregistré par la modification d'une jonction. Dans la pratique, je ne vois pas de projets de le faire très souvent. Généralement à l'aide d'une bibliothèque comme log4j qui vous permet de filtrer par la journalisation et de niveau de la catégorie, au moment de l'exécution si vous en avez besoin, fonctionne assez bien.

    Une préoccupation principale raison est que la demande existe, la logique métier de l'application automatise. Si vous avez de la logistique de l'application qui gère l'expédition de fret, de savoir combien de fret, vous pouvez emballer sur un camion ou quel est le meilleur itinéraire pour le camion à prendre pour y déposer ses livraisons pourrait être le cœur des préoccupations. Les sujets transversaux sont généralement des détails de mise en œuvre qui doivent être séparés de la logique métier.

    • Ainsi, même si le comportement transactionnel vraiment n'existe que dans la couche d'accès aux données, parce que les blocs try-catch sont dupliquées sur de nombreuses méthodes, il est considéré comme transversales. Ma perception est que transversaux signifie le code s'étendait sur plusieurs couches de l'application.
    • transversaux signifie qu'il va à angle droit pour les caractéristiques.
    • par à angle droit, je veux dire: pensez à une fonction comme une pile de calques. un transversales concernent peuvent s'appliquer à une seule couche, mais il est commun à toutes les fonctionnalités.
    • L'autorisation est un bon exemple. J'ai juste refait mon appli pour mettre tout le code d'autorisation dans un transversal de l'architecture et il a fait des merveilles pour nettoyer beaucoup de code. Je considère que le domaine comme une maison. Si vous avez la clé pour obtenir, vous pouvez faire ce que vous voulez là-bas (vous êtes présumé propriétaire). Mais vous ne pouvez pas verrouiller toutes les portes de la maison et de la demande une clé d'entrée. Soit vous êtes ou vous n'êtes pas.
    • "Transactionnelle le problème" peut être commune à de nombreuses fonctionnalités, mais ce ne sera pas "transversales", car il n'est pas "traverser" les couches. La raison, par exemple, l'exploitation forestière est une croix de coupe préoccupation est parce que je peut connecter la couche de présentation, couche, couche de données etc.
    • Donc, multi-tenancy / rôle d'autorisation basé sur le filtrage de la portée serait également une préoccupation horizontale, comme un sous-ensemble de la sécurité, droit?
    • peut-être. difficile de faire une liste de tout le monde d'accord, comme vous pouvez le voir dans les autres commentaires 🙂

    InformationsquelleAutor Nathan Hughes
  3. 12

    En plus de la accepté de répondre, je tiens à mentionner un autre exemple pour un transversales concernent: l'accès distant. Disons que je veux juste appeler d'autres composants dans mon écosystème local, comme si elles étaient en cours d'exécution dans le processus. Peut-être, dans certains cas, ils ont même le faire. Mais maintenant je veux lancer mes services distribués dans un nuage ou d'un cluster. Pourquoi devrais-je me soucier de cet aspect comme un développeur d'applications? Un aspect qui pourrait prendre soin de découvrir qui appeler et et comment, serialising données transmises, si nécessaire, et de faire un appel distant. Si tout ce qui était en cours d'exécution dans le processus de l'aspect voudrais juste avant l'appel local. Sur l'appel de côté l'aspect deserialise les données, faire des appels locaux et de retourner le résultat.

    Maintenant, laissez-moi vous raconter une petite histoire à propos de "trivial" des choses comme la sortie du journal: il y a quelques semaines, j'ai refait un complexe, mais pas trop grosse base de code (autour DE 250 lignes de code) pour un client. En quelques centaines de classes d'un type d'enregistrement cadre a été utilisé, dans un autre quelques centaines de l'autre. Puis, il y avait plusieurs milliers de lignes de System.out.println(*) où il ne devrait vraiment avoir été sortie du journal. Je me suis donc retrouvé avec la fixation des milliers de lignes de code, dispersés à travers la base de code. Heureusement j'ai pu utiliser quelques astuces judicieuses dans IntelliJ IDEA (structurelle de recherche & remplacer) afin d'accélérer l'ensemble de l'action, mais le garçon ne pensez-vous pas que c'est trivial! Bien sûr, fortement dépendante du contexte de l'enregistrement de débogage peuvent toujours se produire à l'intérieur d'un corps de méthode, mais de nombreux types importants de l'exploitation forestière telles que le suivi des appels de méthode (même de façon hiérarchique avec un bien en retrait de sortie), l'exploitation forestière à la fois manipulés ou les exceptions non gérées, audit utilisateur (journalisation des appels restreint à des méthodes basées sur les rôles d'utilisateur) et ainsi de suite peut être facilement mis en œuvre dans les aspects sans eux polluer le code source. Le quotidien de développeur de l'application n'a pas besoin d'y penser ou même de voir l'enregistreur d'appels dispersés à travers la base de code. Quelqu'un est responsable du maintien de l'aspect à jour et peut même changer la stratégie de journalisation ou de l'ensemble de la structure de journalisation centralisée dans un seul endroit.

    Je peux trouver des explications semblables pour d'autres les sujets transversaux. Garder le code propre et libre de diffusion et d'emmêlement de l'OMI est une question de professionnalisme, pas quelque chose de facultatif. Dernier mais non le moins, il conserve le code lisible et maintenable, refactorable. Amen.

    InformationsquelleAutor kriegaex