Ce qui est vraiment intercepteurs faire avec ma classe de c#?

Disons que votre classe doit faire 3 choses pour une certaine opération:

1. Effectuer un contrôle de sécurité;
2. Journal l'appel de la méthode;
3. De mettre en Cache le résultat.

Nous allons supposons que votre classe ne sais rien à propos de la spécifiques façon dont vous avez configuré votre sécurité, l'exploitation forestière et de la mise en cache. Vous avez besoin de dépendre sur des abstractions de ces choses.

Il existe quelques façons d'aller à ce sujet. Un moyen serait de créer un groupe d'interfaces et d'utilisation du constructeur d'injection:

public class OrderService : IOrderService
{
    private readonly IAuthorizationService auth;
    private readonly ILogger logger;
    private readonly ICache cache;

    public OrderService(IAuthorizationService auth, ILogger logger,
        ICache cache)
    {
        if (auth == null)
            throw new ArgumentNullException("auth");
        if (logger == null)
            throw new ArgumentNullException("logger");
        if (cache == null)
            throw new ArgumentNullException("cache");
        this.auth = auth;
        this.logger = logger;
        this.cache = cache;
    }

    public Order GetOrder(int orderID)
    {
        auth.AssertPermission("GetOrder");
        logger.LogInfo("GetOrder:{0}", orderID);
        string cacheKey = string.Format("GetOrder-{0}", orderID);
        if (cache.Contains(cacheKey))
            return (Order)cache[cacheKey];
        Order order = LookupOrderInDatabase(orderID);
        cache[cacheKey] = order;
        return order;
    }
}

Ce n'est pas horrible du code, mais de penser les problèmes que nous allons mettre en place:

• La OrderService classe ne peut pas fonctionner sans tous les trois dépendances. Si nous voulons faire de sorte qu'il peut, nous devons commencer par émaillant le code avec la valeur null vérifie partout.

• Nous sommes en train d'écrire un tonne de code supplémentaire pour effectuer une intervention relativement simple (à la recherche d'un ordre).

• Tous ce code réutilisable doit être répété dans chaque méthode, pour un très grand, laid, bug sujettes à la mise en œuvre.

Voici une classe qui est beaucoup plus facile à entretenir:

public class OrderService : IOrderService
{
    [Authorize]
    [Log]
    [Cache("GetOrder-{0}")]
    public virtual Order GetOrder(int orderID)
    {
        return LookupOrderInDatabase(orderID);
    }
}

Dans La Programmation Orientée Aspects, ces attributs sont appelés Rejoindre Des Points, l'ensemble de ce qui est appelé un Point De Coupe.

Au lieu de l'écrire code de dépendance, plus et plus encore une fois, nous quittons le "les conseils" que certains autres opérations sont censés être effectuée pour cette méthode.

Bien sûr, ces attributs doivent se transformer en code parfois, mais vous pouvez reporter tout le chemin jusqu'à votre code de l'application principale, par la création d'un proxy pour la OrderService (à noter que la GetOrder méthode a été fait virtual car elle a besoin d'être remplacée pour le service), et interception la GetOrder méthode.

L'écriture de l'intercepteur peut être aussi simple que cela:

public class LoggingInterceptor : IInterceptor
{
    public void Intercept(IInvocation invocation)
    {
        if (Attribute.IsDefined(invocation.Method, typeof(LogAttribute))
        {
            Console.Writeline("Method called: "+ invocation.Method.Name);
        }
        invocation.Proceed();
    }
}

Et la création du proxy:

var generator = new ProxyGenerator();
var orderService = (IOrderService)generator.CreateClassProxy(typeof(OrderService),
    new LoggingInterceptor());

Ce n'est pas seulement beaucoup moins de code répétitif, mais il supprime complètement la réelle dépendance, parce que regardez ce que nous avons fait - nous n'avons même pas ont une autorisation ou un système de mise en cache, mais le système fonctionne toujours. Nous pouvons vous suffit d'insérer l'autorisation et la mise en cache de la logique, plus tard, par l'enregistrement d'un autre intercepteur et de vérification pour AuthorizeAttribute ou CacheAttribute.

Espérons-le, c'est ce qui explique le "pourquoi".

Encadré: Que Krzysztof Koźmic commentaires, ce n'est pas une DP sur les "meilleures pratiques" à l'utilisation d'une dynamique de l'intercepteur de ce genre. Dans le code de production, vous ne voulez pas avoir l'intercepteur en cours d'exécution pour inutile de méthodes, afin de l'utiliser un IInterceptorSelector à la place.

OriginalL'auteur Aaronaught