Aspect-Oriented Programming (AOP)

Introduction

Aspect-Oriented Programming (AOP) is about the ability to inject cross-cutting behavior (aspects) in existing code so as to do useful yet somewhat lateral operations transparently. This is called, in Unity terms, interception. Some examples include:

• Logging all method invocations, including parameters.
• Controlling access to a method based on the identity of the current user.
• Catching exceptions and doing something with them.
• Caching the results of a “heavy” operation so that in subsequent executions results come from the cache.

Other examples exist, of course. Aspects are applied to target code in a totally transparent way; that is, you just call your methods in the usual way and interception occurs magically. For now, let’s understand how Unity helps us applying aspects.

Interception Kinds and Techniques

Interception in .NET can be implemented in one of the following five ways:

• Virtual method interception: Dynamically generates a subclass that overrides the virtual methods of the base class so as to add new behavior or suppress the existing one.
• Interface interception: Generates a proxy that will sit behind an interface and its concrete implementation to which all of the interface’s operations will be diverged.
• Transparent proxy interception: Generates a transparent or Remoting proxy to an interface or to an instance of a MarshalByRefObject; this is what Windows Communication Foundation (WCF) proxies use.
• Context bound interception: Leverages the ContextBoundObject class and its associated framework. Since this is very specific and not very usual (because it requires using a base class of type ContextBoundObject), it is not supported by Unity and will not be covered.
• Code weaving: This is probably the most powerful mechanism but it is also a complex one since it involves changing the code on an assembly—in memory as well as in the compiled output file. Unity also does not support it.

Some of these techniques can be applied to existing instances (instance interception) or to Unity-created ones (type interception). In any case, they only apply to instance, not static methods. The following table lists just that:

Table 2: Interception kinds and targets

Interception, if enabled, is applied automatically. But before we can use it, we need to configure what interceptor to use per registration. Unity includes the following interceptors, which cover the most typical scenarios:

• VirtualMethodInterceptor (IInstanceInterceptor)
• InterfaceInterceptor (IInstanceInterceptor)
• TransparentProxyInterceptor (ITypeInterceptor)

The base interfaces that specify the interception kinds, IInstanceInterceptor and ITypeInterceptor, expose a small number of methods. Worthy of note are two methods that both interfaces inherit from IInterceptor:

• CanIntercept: Checks if the interceptor can intercept a given type, passed as parameter.
• GetInterceptableMethods: Returns the list of interceptable methods for a given key-component pair of types, which may include property getters and setters, and event add and remove handlers.

Depending on the registration key, we need to set the proper interceptor; this is the one that will build our interception proxy for the target instance or type. Before we look at how to configure it, let’s understand how interception is implemented. But, even before that, let’s get EnterpriseLibrary.PolicyInjection, a required package from NuGet. This is where all interception-related classes are defined and is a prerequisite for this chapter.

Figure 9: Installing Policy Injection as a NuGet package

Adding Interfaces

We can also add one or more interfaces to the generated proxy. In this case, we will need to implement—either in a behavior or in a call handler (see the next sections)—all of its methods and properties. We shall see an example later on.

Call Handlers

Interception means that all calls to a method, property, event add, or remove handler are diverged to custom code. In it, we decide what to do before or after (or instead of) the call to the original code.

In Unity, the atomic unit by which we can perform interception is the ICallHandler interface. Its interface is very simple:

The Invoke method is the one to where the action actually goes. It receives the execution context—the instance where the method invocation was made and any method parameters—as well as a delegate for the next handler.

The Order property tells Unity how to sort all call handlers that are applied to the same target.

Let’s see an example that measures the time that it took a method to execute:

The call to getNext()(input, getNext) is normally always present in a call handler, and it tells Unity to execute the target method or property that the call handler is intercepting. Its result is a value suitable for returning from Invoke and contains the actual returned value from the intercepted method if it is not void.

The MethodBase property contains a reference to the intercepted method. If you want to see if this method is a property getter or setter, you can use:

Or an event handler add or remove method:

Target is the targeted object instance that contains the intercepted method.

Arguments contains a collection of all method parameters, if any.

InvocationContext is a general-purpose dictionary indexed by string and storing objects, where call handlers targeting the same method or property can share data.

After calling the base implementation, we get a result from which we can obtain the actual returned value, if the method was not void (ReturnValue) and did not return an exception or the exception that was thrown (Exception).

If we want to return a value without actually executing the intercepted method, we can use the CreateMethodReturn method. In its simplest form, it just takes a value to return for non-void methods which, of course, must match the method’s expected return type:

And, if we want to return an exception instead, we call CreateExceptionMethodReturn:

If we have two call handlers configured for the same method, we can pass values from the first to the second:

Interception Behaviors

A call handler only applies to a single interception target (a method or property). Unity offers another construction for intercepting all calls to all interceptable members of a class, called an interception behavior.

An interception behavior is a class that implements IInterceptionBehavior. Again, it is a simple interface although slightly more complex than ICallHandler. Its contract is this:

Method GetRequiredInterfaces is a way developers can use to force the behavior to only run if the target class implements one or more specific interfaces. In most cases, we just return an empty collection.

Invoke is exactly the same as in ICallHandler so there’s no point in discussing it again.

Property WillExecute is used to tell Unity if the behavior should be applied or not. If it returns false, method Invoke will not run.

Note: Since WillExecute receives no context, it is hard to use. Most of the time we just return true.

Note: The difference between call handlers and behaviors is that behaviors intercept all interceptable methods in a class whereas call handlers intercept just one.

A simple interception behavior:

Configuring Interception by Attributes

We configure interception on an interceptable property or method by applying a HandlerAttribute that returns an instance of an ICallHandler. For example, imagine you have an implementation of ICallHandler called CachingHandler, you could write a host attribute for it as this:

After we have our attribute, it’s just a matter of applying it to a method. When Unity resolves the containing class, it will recognize it:

See chapter Chapter 5  Extending Unity for a full implementation.

Note: Interception attributes can be applied to either the key or the component type.

Configuring Interception by Code

Applying Interception

First, we need to tell Unity to use the Interception extension:

We have two basic options:

• Register an injection behavior
• Register a call handler

Interception Behaviors

Interception behaviors are injected at registration time using the RegisterType method, like in the following example in which we add a MyInterceptionBehavior to the FileLogger:

Note: You can add several interception behaviors; all will be applied in sequence.

Notice how we define the interceptor to use (InterfaceInterceptor); it is also possible to configure it as the default for a type:

And this is it. Every time you ask for a FileLogger instance, you will get a proxy that includes the MyInterceptionBehavior.

Call Handlers

Call handlers are a bit trickier to apply because we need to define to which member or members they will apply. For that, we add call handler types (AddCallHandler or AddCallHandler<T>) or instances (AddCallHandler) to a policy (AddPolicy) and a set of rules (AddMatchingRule):

Tip: You should add a call handler instance instead of its type if the call handler requires special configuration (like setting its execution order or if it doesn’t have a public, parameterless constructor).

This example has two rules:

• A TypeMatchingRule: Matches when the member is declared in the given type.
• A MemberNameMatchingRule: Matches when the given member name is the same as the one supplied in the constructor.

Tip: The call handler is only applied if all rules match.

Tip: You can add any number of call handlers; they will be processed and sorted by their Order property.

A rule must implement IMatchingRule, which exposes a very simple interface:

There are several rules included out of the box:

• AssemblyMatchingRule: Matches the assembly name of the given member.
• AttributeDrivenPolicyMatchingRule: Checks to see if the member (or type containing that member) has any HandlerAttribute.
• CustomAttributeMatchingRule: Checks to see if the member tested has an arbitrary attribute applied.
• MethodSignatureMatchingRule: Matches methods with the given names and method signature.
• NamespaceMatchingRule: Matches members in a given namespace. You can specify either a single namespace (e.g., System.Data) or a namespace root (e.g., System.Data.* to match types in that namespace or below).
• ParameterTypeMatchingRule: Matches methods that have any parameters of the given types.
• PropertyMatchingRule: Matches properties by name. You can match the getter, setter, or both.
• ReturnTypeMatchingRule: Checks to see if a member has a specified type.
• TagAttributeMatchingRule: Checks a member for the presence of the TagAttribute on the method, property, or class, and that it matches a specific tag.

You can easily implement your own rules; see an example in Policy Rules.

Note: All rules that take names accept regular expressions.

Adding Interfaces to Interception Proxies

When we register a type for interception, we can add additional interfaces that Unity will add to the generated proxy. The injection member classes used for this purpose are AdditionalInterface and AdditionalInterface<T>. Here is one example of its usage:

This tells Unity to add interface IDisposable to all proxies to FileLogger and to apply a DisposableBehavior. The result of calling Resolve will then implement the IDisposable interface and the Dispose method is available for invocation. Of course, because this method was not implemented by the FileLogger class, it is up to the DisposableBehavior to make sure that, if the method is called, something happens.

If you add some interface to a class, you have to implement all of the interface’s methods and properties. A common example is adding support for INotifyPropertyChanged, which is a very useful interface that is somewhat cumbersome to implement when there are many properties. Let’s see how we can do it automatically with an interception behavior.

First, the registration; this is where we add the INotifyPropertyChanged, set the interceptor (VirtualMethodInterceptor in this case), and set the interceptor class:

The NotifyPropertyChangedInterceptionBehavior class:

And a sample usage:

Configuring Interception by XML

Applying Interception

When using XML configuration, we usually register the Unity extension (Interception) for applying the interception functionality and a section extension (InterceptionConfigurationExtension) that allows the configuration of it in XML:

Interception Behaviors

Behaviors are configured inside the register declaration, in an interceptionBehavior element:

The interceptionBehavior allows three attributes:

• name (optional): A name that, if supplied, causes Unity to resolve the behavior instead of just creating a new instance.
• type (required): The behavior type (a class that implements IInterceptionBehavior).
• isDefaultForType (optional): If true, the behavior will be applied to all registrations of this type; the default is false.

Call Handlers

Call handlers are, as you know, slightly more complicated because of the matching rules:

I believe that the new sections interceptors, default, policy, matchingRule, and callHandler are self-explanatory so there’s really nothing to add here. Do notice the interceptor declaration inside register; this is required so that Unity knows what interceptor to use.

Adding Interfaces to Interception Proxies

This is all it takes to add a new element, addInterface, to the register declaration:

Applying Interception in an Existing Instance

An alternative approach to resolving an intercepted component from Unity is to generate a runtime proxy through an interface to an existing instance. In the process, we can add a number of interception behaviors and even interfaces. We do that by calling one of the ThroughProxy overloads:

Do note that this only works through interfaces and that the existing instance is left untouched.

Included Call Handlers

The Enterprise Library—of which Unity is a part—includes a number of call handlers that you can use in your code:

1. Table 3: Included call handlers

Note: Some of these call handlers require a specific installation procedure. Don’t forget to read their documentation.