Aspect-Oriented Programming : Aspect-Oriented Programming with the RealProxy Class

Aspect-Oriented Programming : Aspect-Oriented Programming with the RealProxy Class

A well-architected application has separate layers so different concerns don’t interact more than needed. Imagine you’re designing a loosely coupled and maintainable application, but in the middle of the development, you see some requirements that might not fit well in the architecture, such as:

• The application must have an authentication system, used before any query or update.
• The data must be validated before it’s written to the database.
• The application must have auditing and logging for sensible operations.
• The application must maintain a debugging log to check if operations are OK.
• Some operations must have their performance measured to see if they’re in the desired range.

Any of these requirements need a lot of work and, more than that, code duplication. You have to add the same code in many parts of the system, which goes against the “don’t repeat yourself” (DRY) principle and makes maintenance more difficult. Any requirement change causes a massive change in the program. When I have to add something like that in my applications, I think, “Why can’t the compiler add this repeated code in multiple places for me?” or, “I wish I had some option to ‘Add logging to this method.’”

The good news is that something like that does exist: aspect-oriented programming (AOP). It separates general code from aspects that cross the boundaries of an object or a layer. For example, the application log isn’t tied to any application layer. It applies to the whole program and should be present everywhere. That’s called a crosscutting concern.

AOP is, according to Wikipedia, “a programming paradigm范例 that aims to increase modularity模块性 by allowing the separation of crosscutting concerns.” It deals with functionality that occurs in multiple parts of the system and separates it from the core of the application, thus improving separation of concerns while avoiding duplication of code and coupling.

In this article, I’ll explain the basics of AOP and then detail how to make it easier by using a dynamic proxy via the Microsoft .NET Framework class RealProxy.

Implementing AOP

The biggest advantage of AOP is that you only have to worry about the aspect in one place, programming it once and applying it in all the places where needed. There are many uses for AOP, such as:

• Implementing logging in your application.
• Using authentication before an operation (such as allowing some operations only for authenticated users).
• Implementing validation or notification for property setters (calling the PropertyChanged event when a property has been changed for classes that implement the INotifyPropertyChanged interface).
• Changing the behavior of some methods.

As you can see, AOP has many uses, but you must wield使用 it with care. It will keep some code out of your sight, but it’s still there, running in every call where the aspect is present. It can have bugs and severely严重地 impact the performance of the application. A subtle微妙的 bug in the aspect might cost you many debugging hours. If your aspect isn’t used in many places, sometimes it’s better to add it directly to the code.

AOP implementations use some common techniques:

• Adding source code using a pre-processor, such as the one in C++.
• Using a post-processor to add instructions on the compiled binary code.
• Using a special compiler that adds the code while compiling.
• Using a code interceptor拦截器 at run time that intercepts execution and adds the desired code.

In the .NET Framework, the most commonly used of these techniques are post-processing and code interception.

The former is the technique used by PostSharp (postsharp.net) and the latter is used by dependency injection (DI) containers such as Castle DynamicProxy (bit.ly/JzE631) and Unity (unity.codeplex.com).

These tools usually use a design pattern named Decorator or Proxy to perform the code interception.

The Decorator Design Pattern

The Decorator design pattern solves a common problem: You have a class and want to add some functionality to it. You have several options for that:

• You could add the new functionality to the class directly. However, that gives the class another responsibility and hurts the “single responsibility” principle.
• You could create a new class that executes this functionality and call it from the old class. This brings a new problem: What if you also want to use the class without the new functionality?
• You could inherit a new class and add the new functionality, but that may result in many new classes. For example, let’s say you have a repository class for create, read, update and delete (CRUD) database operations and you want to add auditing. Later, you want to add data validation to be sure the data is being updated correctly. After that, you might also want to authenticate the access to ensure that only authorized users can access the classes. These are big issues: You could have some classes that implement all three aspects, and some that implement only two of them or even only one. How many classes would you end up having?
• You can “decorate” the class with the aspect, creating a new class that uses the aspect and then calls the old one. That way, if you need one aspect, you decorate it once. For two aspects, you decorate it twice and so on. Let’s say you order a toy (as we’re all geeks, an Xbox or a smartphone is OK). It needs a package for display in the store and for protection. Then, you order it with gift wrap, the second decoration, to embellish装饰 the box with tapes, stripes, cards and gift paper. The store sends the toy with a third package, a box with Styrofoam balls for protection. You have three decorations, each one with a different functionality, and each one independent from one another. You can buy your toy with no gift packaging, pick it up at the store without the external box or even buy it with no box (with a special discount!). You can have your toy with any combination of the decorations, but they don’t change its basic functionality.

Now that you know about the Decorator pattern, I’ll show how to implement it in C#.

First, create an interface IRepository<T>:

  public interface IRepository<T>
    {
        void Add(T entity);
        void Delete(T entity);
        void Update(T entity);
        IEnumerable<T> GetAll();
        T GetById(int id);
    }

Implement it with the Repository<T> class

public class Repository<T> : IRepository<T>
    {
        public void Add(T entity)
        {
            Console.WriteLine("Adding {0}", entity);
        }

        public void Delete(T entity)
        {
            Console.WriteLine("Deleting {0}", entity);
        }

        public void Update(T entity)
        {
            Console.WriteLine("Updating {0}", entity);
        }

        public IEnumerable<T> GetAll()
        {
            Console.WriteLine("Getting entities");
            return null;
        }

        public T GetById(int id)
        {
            Console.WriteLine("Getting entity {0}", id);
            return default(T);
        }
    }

Use the Repository<T> class to add, update, delete and retrieve the elements of the Customer class

 public class Customer
    {
        public int Id { get; set; }
        public string Name { get; set; }
        public string Address { get; set; }
    }

The program could look something like

class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("***
 Begin program - no logging
");
            IRepository<Customer> customerRepository =
                new Repository<Customer>();
            var customer = new Customer
            {
                Id = 1,
                Name = "Customer 1",
                Address = "Address 1"
            };
            customerRepository.Add(customer);
            customerRepository.Update(customer);
            customerRepository.Delete(customer);
            Console.WriteLine("
End program - no logging
***");
            Console.ReadLine();
        }
    }

 When you run this code, you’ll see something like 

***
Begin program - no logging

Adding AOPTest.Customer
Updating AOPTest.Customer
Deleting AOPTest.Customer

End program - no logging
***

C:Usersclusource eposGitHubChuckLuTestAOPTestAOPTestinDebug etcoreapp3.0AOPTest.exe (process 28984) exited with code -1.
To automatically close the console when debugging stops, enable Tools->Options->Debugging->Automatically close the console when debugging stops.
Press any key to close this window . . .

Imagine your boss asks you to add logging to this class.

You can create a new class that will decorate IRepository<T>.

It receives the class to build and implements the same interface, as shown 

 public class LoggerRepository<T> : IRepository<T>
    {
        private readonly IRepository<T> _decorated;
        public LoggerRepository(IRepository<T> decorated)
        {
            _decorated = decorated;
        }

        private void Log(string msg, object arg = null)
        {
            Console.ForegroundColor = ConsoleColor.Red;
            Console.WriteLine(msg, arg);
            Console.ResetColor();
        }

        public void Add(T entity)
        {
            Log("In decorator - Before Adding {0}", entity);
            _decorated.Add(entity);
            Log("In decorator - After Adding {0}", entity);
        }

        public void Delete(T entity)
        {
            Log("In decorator - Before Deleting {0}", entity);
            _decorated.Delete(entity);
            Log("In decorator - After Deleting {0}", entity);
        }

        public void Update(T entity)
        {
            Log("In decorator - Before Updating {0}", entity);
            _decorated.Update(entity);
            Log("In decorator - After Updating {0}", entity);
        }

        public IEnumerable<T> GetAll()
        {
            Log("In decorator - Before Getting Entities");
            var result = _decorated.GetAll();
            Log("In decorator - After Getting Entities");
            return result;
        }

        public T GetById(int id)
        {
            Log("In decorator - Before Getting Entity {0}", id);
            var result = _decorated.GetById(id);
            Log("In decorator - After Getting Entity {0}", id);
            return result;
        }
    }

This new class wraps the methods for the decorated class and adds the logging feature. You must change the code a little to call the logging class, as shown

class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("***
 Begin program - no logging
");
            IRepository<Customer> customerRepository =
                new LoggerRepository<Customer>(new Repository<Customer>());
            var customer = new Customer
            {
                Id = 1,
                Name = "Customer 1",
                Address = "Address 1"
            };
            customerRepository.Add(customer);
            customerRepository.Update(customer);
            customerRepository.Delete(customer);
            Console.WriteLine("
End program - no logging
***");
            Console.ReadLine();
        }
    }

You simply create the new class, passing an instance of the old class as a parameter for its constructor. When you execute the program, you can see it has the logging, as shown in

 You might be thinking: “OK, the idea is good, but it’s a lot of work: I have to implement all the classes and add the aspect to all the methods. That will be difficult to maintain. Is there another way to do it?” With the .NET Framework, you can use reflection to get all methods and execute them. The base class library (BCL) even has the RealProxy class (bit.ly/18MfxWo) that does the implementation for you.

https://docs.microsoft.com/en-us/dotnet/api/system.runtime.remoting.proxies.realproxy?redirectedfrom=MSDN&view=netframework-4.8

Creating a Dynamic Proxy with RealProxy

The RealProxy class gives you basic functionality for proxies.

It’s an abstract class that must be inherited by overriding its Invoke method and adding new functionality.

This class is in the namespace System.Runtime.Remoting.Proxies.

To create a dynamic proxy, you use code similar to Figure 7.

RealProxy in dotnet core?

public class DynamicProxy<T> : RealProxy
    {
        private readonly T _decorated;
        public DynamicProxy(T decorated)
            : base(typeof(T))
        {
            _decorated = decorated;
        }
        private void Log(string msg, object arg = null)
        {
            Console.ForegroundColor = ConsoleColor.Red;
            Console.WriteLine(msg, arg);
            Console.ResetColor();
        }
        public override IMessage Invoke(IMessage msg)
        {
            var methodCall = msg as IMethodCallMessage;
            var methodInfo = methodCall.MethodBase as MethodInfo;
            Log("In Dynamic Proxy - Before executing '{0}'",
                methodCall.MethodName);
            try
            {
                var result = methodInfo.Invoke(_decorated, methodCall.InArgs);
                Log("In Dynamic Proxy - After executing '{0}' ",
                    methodCall.MethodName);
                return new ReturnMessage(result, null, 0,
                    methodCall.LogicalCallContext, methodCall);
            }
            catch (Exception e)
            {
                Log(string.Format(
                        "In Dynamic Proxy- Exception {0} executing '{1}'", e),
                    methodCall.MethodName);
                return new ReturnMessage(e, methodCall);
            }
        }
    }

In the constructor of the class, you must call the constructor of the base class, passing the type of the class to be decorated. Then you must override the Invoke method that receives an IMessage parameter. It contains a dictionary with all the parameters passed for the method. The IMessage parameter is typecast to an IMethodCallMessage, so you can extract the parameter MethodBase (which has the MethodInfo type).

The next steps are to add the aspect you want before calling the method, call the original method with methodInfo.Invoke and then add the aspect after the call.

You can’t call your proxy directly, because DynamicProxy<T> isn’t an IRepository<Customer>. That means you can’t call it like this:

IRepository<Customer> customerRepository =
  new DynamicProxy<IRepository<Customer>>(
  new Repository<Customer>());

To use the decorated repository, you must use the GetTransparentProxy method, which will return an instance of IRepository<Customer>.

Every method of this instance that’s called will go through the proxy’s Invoke method.

To ease this process, you can create a Factory class to create the proxy and return the instance for the repository:

 public class RepositoryFactory
    {
        public static IRepository<T> Create<T>()
        {
            var repository = new Repository<T>();
            var dynamicProxy = new DynamicProxy<IRepository<T>>(repository);
            return dynamicProxy.GetTransparentProxy() as IRepository<T>;
        }
    }

That way, the main program will be similar to 

 class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("***
 Begin program - no logging
");
            IRepository<Customer> customerRepository =
                RepositoryFactory.Create<Customer>();
            var customer = new Customer
            {
                Id = 1,
                Name = "Customer 1",
                Address = "Address 1"
            };
            customerRepository.Add(customer);
            customerRepository.Update(customer);
            customerRepository.Delete(customer);
            Console.WriteLine("
End program - no logging
***");
            Console.ReadLine();
        }
    }

As you can see, you’ve created a dynamic proxy that allows adding aspects to the code, with no need to repeat it.

If you wanted to add a new aspect, you’d only need to create a new class, inherit from RealProxy and use it to decorate the first proxy.

If your boss comes back to you and asks you to add authorization to the code, so only administrators can access the repository, you could create a new proxy as shown in

public class AuthenticationProxy<T> : RealProxy
    {
        private readonly T _decorated;
        public AuthenticationProxy(T decorated)
            : base(typeof(T))
        {
            _decorated = decorated;
        }
        private void Log(string msg, object arg = null)
        {
            Console.ForegroundColor = ConsoleColor.Green;
            Console.WriteLine(msg, arg);
            Console.ResetColor();
        }
        public override IMessage Invoke(IMessage msg)
        {
            var methodCall = msg as IMethodCallMessage;
            var methodInfo = methodCall.MethodBase as MethodInfo;
            if (Thread.CurrentPrincipal.IsInRole("ADMIN"))
            {
                try
                {
                    Log("User authenticated - You can execute '{0}' ",
                        methodCall.MethodName);
                    var result = methodInfo.Invoke(_decorated, methodCall.InArgs);
                    return new ReturnMessage(result, null, 0,
                        methodCall.LogicalCallContext, methodCall);
                }
                catch (Exception e)
                {
                    Log(string.Format(
                            "User authenticated - Exception {0} executing '{1}'", e),
                        methodCall.MethodName);
                    return new ReturnMessage(e, methodCall);
                }
            }
            Log("User not authenticated - You can't execute '{0}' ",
                methodCall.MethodName);
            return new ReturnMessage(null, null, 0,
                methodCall.LogicalCallContext, methodCall);
        }
    }

The repository factory must be changed to call both proxies, as shown

 The Repository Factory Decorated by Two Proxies

  public class RepositoryFactory
    {
        public static IRepository<T> Create<T>()
        {
            var repository = new Repository<T>();
            var decoratedRepository =
                (IRepository<T>)new DynamicProxy<IRepository<T>>(
                    repository).GetTransparentProxy();
            // Create a dynamic proxy for the class already decorated
            decoratedRepository =
                (IRepository<T>)new AuthenticationProxy<IRepository<T>>(
                    decoratedRepository).GetTransparentProxy();
            return decoratedRepository;
        }
    }

When you change the main program to Figure 12 and run it, you’ll get the output shown

 class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine(
                "***
 Begin program - logging and authentication
");

            Console.WriteLine("
Running as admin");
            Thread.CurrentPrincipal =
                new GenericPrincipal(new GenericIdentity("Administrator"),
                    new[] { "ADMIN" });
            IRepository<Customer> customerRepository =
                RepositoryFactory.Create<Customer>();
            var customer = new Customer
            {
                Id = 1,
                Name = "Customer 1",
                Address = "Address 1"
            };
            customerRepository.Add(customer);
            customerRepository.Update(customer);
            customerRepository.Delete(customer);


            Console.WriteLine("
Running as user");
            Thread.CurrentPrincipal =
                new GenericPrincipal(new GenericIdentity("NormalUser"),
                    new string[] { });
            customerRepository.Add(customer);
            customerRepository.Update(customer);
            customerRepository.Delete(customer);
            Console.WriteLine(
                "
End program - logging and authentication
***");
            Console.ReadLine();
        }
    }

The program executes the repository methods twice. The first time, it runs as an admin user and the methods are called. The second time, it runs as a normal user and the methods are skipped.

That’s much easier, isn’t it? Note that the factory returns an instance of IRepository<T>, so the program doesn’t know if it’s using the decorated version.

This respects the Liskov Substitution Principle, which says that if S is a subtype of T, then objects of type T may be replaced with objects of type S. In this case, by using an IRepository<Customer> interface, you could use any class that implements this interface with no change in the program.

Not a Replacement

With AOP you can add code to all layers of your application in a centralized way, with no need to repeat code. I showed how to create a generic dynamic proxy based on the Decorator design pattern that applies aspects to your classes using events and a predicate to filter the functions you want.

As you can see, the RealProxy class is a flexible class and gives you full control of the code, with no external dependencies. However, note that RealProxy isn’t a replacement for other AOP tools, such as PostSharp. PostSharp uses a completely different method. It will add intermediate language (IL) code in a post-compilation step and won’t use reflection, so it should have better performance than RealProxy. You’ll also have to do more work to implement an aspect with RealProxy than with PostSharp. With PostSharp, you need only create the aspect class and add an attribute to the class (or the method) where you want the aspect added, and that’s all.

On the other hand, with RealProxy, you’ll have full control of your source code, with no external dependencies, and you can extend and customize it as much as you want. For example, if you want to apply an aspect only on methods that have the Log attribute, you could do something like this: