J'ai une application WebFormes ASP.NET 3.5 SP1 SP1. J'utilise le motif MVP (contrôleur de supervision) avec DI (autofac). Mes présentateurs appellent aux contrats de référentiel définis dans mon domaine (DDD) mis en œuvre dans un projet d'infrastructure.
Méthodes de référentiel Les présentateurs appellent peuvent Hork, alors j'ai besoin de loger des exceptions, puis de définir un message d'erreur à la vue.
Dans le passé, j'aurais ajouté un autre paramètre sur les constructeurs de présentateurs, stocké la référence dans un présentateur de base et appelé méthode de journal dans mes blocs de capture. Je n'aime pas vraiment ça, mais ça fait le travail.
Je pourrais aller la voie d'utiliser une usine pour obtenir la classe de journalisation Comme décrit ici , mais j'aimerais d'abord explorer un AOP, car il semble assez intéressant.
J'ai fait la lecture sur la compilée VS Runtime AOP, et j'aimerais savoir quelles expériences des peuples sont avec les différentes solutions, des plus, des minuss, des mots de conseil, etc.
de la creuse que j'ai fait, il semble qu'il y ait 4 cadres principaux pour AOP dans .NET
Je vois Une autre question qui a de bonnes réponses mais d'une année d'une année et demie. Existe-t-il plus récent, "mieux", des cadres développés entre-temps ou des améliorations apportées aux solutions existantes qui devraient être prises en compte?
Pour référence, j'ai choisi Autofac pour DI parce que son utilisation fluide, simple à utiliser, n'a pas pu trouver de commentaires négatifs à ce sujet, et cela fonctionne simplement.
Y a-t-il des recommandations sur lesquelles le cadre de l'AOP devrais-je essayer? Merci d'avoir lu tout cela et d'ajouter des pensées.
3 Réponses :
J'ai utilisé PostShaRP depuis un certain temps et je dois dire que je profite de la facilité d'utilisation et de la simplicité de la mise en œuvre.
Je dois également ajouter que personnellement, lorsque j'utilise un cadre, j'essaie toujours de coller avec un cadre unique de responsabilité, à moins que le cadre ne contienne beaucoup de composants que j'ai besoin ou complimentant le noyau.
Réponse courte, pour la simplicité et la facilité d'utilisation, vous ne pouvez vraiment pas vous tromper avec PostSharp.
Réponse plus longue: Dans mon esprit, vous devez choisir entre les deux cadres en fonction de ce que vous essayez d'atteindre.
Si vous voulez des aspects qui devraient changer en fonction du contexte, envisagez Spring.net (ou tout cadre AOP injectant le code à l'exécution basé sur la configuration). Cela vous permet de personnaliser le comportement de vos objets en fonction de ce que vous faites. Par exemple, via votre configuration, vous pouvez utiliser un type de journalisation dans une application de console et une autre dans une application Web. Notez que le printemps est également un conteneur di (et plusieurs autres choses) - il va bien au-delà de l'AOP, et il vaut vraiment la peine d'apprendre à utiliser.
D'autre part, si vous voulez un comportement qui devrait toujours être en vigueur, quel que soit le contexte, la post-postparp (compilez le tisserie) est votre meilleur choix. Ceci est effectivement le même que si vous incluez le code dans chaque méthode que vous appliquez l'aspect à.
Pour ce que vous faites, je vous recommande de commencer avec PostSharp.
Merci pour l'entrée, acceptant la meilleure réponse à la question.
599 € par développeur * posthars ultime
Pour des scénarios de simple aspect, je passerais le corps de la méthode comme un bloc à une méthode générique qui gère l'aspect, c'est-à-dire la mise en œuvre de Le« trou dans le modèle de conception »du Middle» .
Exemple:
S'il vous plaît, ajoutez un commentaire lorsque le vote de descente.
-1 Cette technique ne concerne pas un AOP
Le concept d'AOP est injecté un comportement au code existant sans modifier la mise en œuvre existante. Dans cet exemple, si vous décidez de modifier l'aspect, vous devez refroidir tout le code.
Je serais intéressé par les détails de la raison pour laquelle vous voulez utiliser un AOP. Je suis encore de trouver un scénario où il était assez bon pour répondre à mes besoins. Par exemple, la journalisation. Les enregistreurs AOP peuvent me dire quand une méthode spécifique est touchée, mais ce n'est jamais assez d'informations. J'ai toujours besoin d'utiliser un enregistreur à l'intérieur de la méthode ainsi que autour de . Je serais intéressé par la façon dont AOP vous aiderait. Je ne m'éloigne pas sur un AOP - je suis juste sceptique et je cherche ce que les scénarios du monde réel sont vraiment convaincus d'entreprendre l'AOP Goo.
J'ai mentionné dans la question que c'est pour les exceptions de journalisation pour le moment.
Votre point est bien pris en arrière. J'ai fini par utiliser une usine avec un délégué pour créer l'enregistreur qui a été mis en place sur mon conteneur IOC. Dans la période donnée, je n'ai pas descendu la voie de l'AOP, mais je suis toujours intéressé à voir à quel point cela peut être utile.
L'enregistrement général est souvent utilisé comme bon exemple d'utilisation pour AOP, mais ce n'est pas vraiment vrai! ... pour la raison exacte que vous mentionnez que si je peux résumer, c'est "chaque endroit où vous devez vous connecter pour vous connecter quelque chose de spécifique" . La traçage d'autre part est une utilisation idéale de l'AOP, car les conseils de cette affaire sont très génériques et sont les mêmes dans tous les cas. Toutefois, après avoir dit que, Exception la journalisation peut être rendue générique, donc je pense que dans ce cas serait un bon candidat à l'AOP. Ceci est toute la théorie car je n'ai commencé que d'étudier l'AOP: -}
Hmm. Même avec la journalisation des exceptions, l'AOP ne semble pas fonctionner assez bien. La plupart du temps, j'essaye / attrape et reproduit l'erreur dans une méthode afin qu'elle fournisse des informations plus spécifiques et donc plus utiles pour l'utilisateur / développeur.