Third Shelf

As part of designing our AOP.NET framework, I thought it best to start with the end in mind. What that entails is to figure out what our proxy class should look like. Let’s start with a simple interface and then design the proxy class according to the interface.

public interface IVehicle
{
  string Make{get;set;}
  void Start();
  void Stop();
}

If only all things in life could be so simple. What do we expect from our proxy class? First of all, it should proxy the call to the target instance.

But before the call is made to the target instance, it should first call our aspect class. Assume, for now, that our aspect just logs an entry whenever a call is made to one of the members.

That means that we would expect our proxy class to look something like this:

[Proxy]
public sealed class IVehicle_LogAspect_Proxy : IVehicle
{
  private IVehicle _TargetInstance;
  private ILoggerAspect _LoggerAspect;

  public IVehicle_LogAspect_Proxy(
    IVehicle targetInstance, ILoggerAspect loggerAspect)
  {
    _TargetInstance = targetInstance;
    _LoggerAspect = loggerAspect;
  }

  public string Make
  {
    get
    {
      _LoggerAspect.Log("Make.Get");
      return _TargetInstance.Make;
    }
    set
    {
      _LoggerAspect.Log("Make.Set");
      _TargetInstance.Make = value;
    }
  }

  public void Start()
  {
    _LoggerAspect.Log("Start");
    _TargetInstance.Start();
  }

  public void Stop()
  {
    _LoggerAspect.Log("Stop");
    _TargetInstance.Stop();
  }
}

First, there is a Proxy attribute applied to the proxy class. This is just to identify the class as a proxy type. Sometimes it might be necessary for calling code to know whether it is dealing with a real object or a proxy. The attribute facilitates this quite nicely.

Naming the type is a matter of concatenating the interface names, separated by underscores together with the aspect that is injected. Finally, we simply just add the word Proxy to the type name to help with identification.

After all that the constructor is next. The constructor plays a vital role in the proxy as it receives the reference to the target instance as well as the reference to the aspect instance. Both these references are assigned to private variables by the constructor.

As you can see, the aspect method is directly injected into the member, before the call is passed to the target instance.

The advantages of doing it this way are that all the heavy aspect code is outside of the proxy class, which makes it a lot simpler to write and maintain.

Now that we have an idea of what the proxy class should look like we will next look at the framework building blocks.

Problem:

A business software package has cross-cutting functionality across its domain objects. This leads to duplicated code and needs to be generalised.

Solution:

Produce a general proxy aspect framework for applying aspects to domain objects.

Note: The framework that we are going to construct is for a specific scenario and is not intended to compete with other aspect oriented frameworks out there. It is intended to demonstrate the principles and considerations that need to be taken into account when applying aspects to domain objects.

Prerequisite:

Every domain object must be defined by an interface.

Requirements:

At a high level our requirements for the proxy aspect framework are as follows:

• Support multiple aspects per domain object;
• Generated proxy must at least implement the domain objects interface;
• Support aspects that need to implement their own interfaces on the proxy;
• Collections must be applied the same aspects as the domain object it is defined on;
• Proxy types must be cached;
• Support the ability to place intercepting calls before and/or after the call to the target instance;
• Must be able to save the assembly containing all proxy types;
• Must be able to intercept methods, events and properties.

Next, we will discuss the framework design.

A proxy aspect approach is one of many approaches in Aspect Oriented Programming. The general idea behind AOP is to deal with the problem of cross-cutting concerns.

Let’s say you want to check the permissions of a user before executing a method (this is the type of aspect that we want to apply to our object). You can appreciate that when a system is beyond “Hello World!” that this can turn out to be quite a thing to remember and apply on every method.

To solve this problem we would need to inject this call into the methods where this security check needs to be done. This can be done in various ways, such as creating a proxy at runtime that performs the check or alter the assemblies with another tool after compilation.

Over the next couple of weeks, I will walk you through the requirements, design and construction of one of these approaches that I call; you guessed it; the proxy aspect approach.

At a high level, the idea is to create a proxy for every object that needs to have certain functionality executed as soon as, for example, a method is entered or a property is changed. In effect, the object will have multiple layers or proxies to which all calls; that are intended for the target instance; are directed.

One proxy is created for each aspect that is applied, and every proxy object carries a reference to the instance of the target instance. This target instance can either be another proxy object or the final domain object, say.

When the call is made to the proxy object it will execute the aspect code and then forward the call to the target instance. If the target instance is a proxy, the same process will happen again until it reaches the inner most target instance where the call is finally handled. If there are results that need to be returned, it passes back up through every proxy until it reaches the original caller.

Next, we’ll have a look at the requirements.