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 GetAll();
- T GetById(int id);
Implement it with the Repository<T> class, shown in Figure 1.
Figure 1 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 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 Figure 2.
Figure 2 The Main Program, with No Logging
- static void Main(string[] args)
- Console.WriteLine(“***\r\n Begin program – no logging\r\n”);
- IRepository 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(“\r\nEnd program – no logging\r\n***”);
- Console.ReadLine();
When you run this code, you’ll see something like Figure 3.
Figure 3 Output of the Program with No Logging
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 in Figure 4.
Figure 4 The Logger Repository
- public class LoggerRepository<T> : IRepository<T>
- private readonly IRepository _decorated;
- public LoggerRepository(IRepository 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 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 inFigure 5.
Figure 5 The Main Program Using The Logger Repository
- static void Main(string[] args)
- Console.WriteLine(“***\r\n Begin program – logging with decorator\r\n”);
- // IRepository customerRepository =
- // new Repository<Customer>();
- IRepository 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(“\r\nEnd program – logging with decorator\r\n***”);
- 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 Figure 6.
Figure 6 Execution of the Logging Program with a Decorator
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.
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.
Figure 7 The Dynamic Proxy Class
- class DynamicProxy : 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);
- 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. 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>(repository);
- return dynamicProxy.GetTransparentProxy() as IRepository;
That way, the main program will be similar to Figure 8.
Figure 8 The Main Program with a Dynamic Proxy
- static void Main(string[] args)
- Console.WriteLine(“***\r\n Begin program – logging with dynamic proxy\r\n”);
- // IRepository<Customer> customerRepository =
- // new Repository<Customer>();
- // IRepository<Customer> customerRepository =
- // new LoggerRepository<Customer>(new Repository<Customer>());
- 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(“\r\nEnd program – logging with dynamic proxy\r\n***”);
- Console.ReadLine();
When you execute this program, you get a similar result as before, as shown inFigure 9.
Figure 9 Program Execution with Dynamic Proxy
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 Figure 10.
Figure 10 An Authentication Proxy
- class AuthenticationProxy : 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”))
- 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 in Figure 11.
Figure 11 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 in Figure 13.
Figure 12 The Main Program Calling the Repository with Two Users
- static void Main(string[] args)
- Console.WriteLine(
- “***\r\n Begin program – logging and authentication\r\n”);
- Console.WriteLine(“\r\nRunning 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(“\r\nRunning as user”);
- Thread.CurrentPrincipal =
- new GenericPrincipal(new GenericIdentity(“NormalUser”),
- new string[] { });
- customerRepository.Add(customer);
- customerRepository.Update(customer);
- customerRepository.Delete(customer);
- Console.WriteLine(
- “\r\nEnd program – logging and authentication\r\n***”);
- Console.ReadLine();
Figure 13 Output of the Program Using Two Proxies
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 interface, you could use any class that implements this interface with no change in the program.
Filtering Functions
Until now, there was no filtering in the functions; the aspect is applied to every class method that’s called. Often this isn’t the desired behavior. For example, you might not want to log the retrieval methods (GetAll and GetById). One way to accomplish this is to filter the aspect by name, as in Figure 14.
Figure 14 Filtering Methods for the Aspect
- public override IMessage Invoke(IMessage msg)
- var methodCall = msg as IMethodCallMessage;
- var methodInfo = methodCall.MethodBase as MethodInfo;
- if (!methodInfo.Name.StartsWith(“Get”))
- Log(“In Dynamic Proxy – Before executing ‘{0}'”,
- methodCall.MethodName);
- var result = methodInfo.Invoke(_decorated, methodCall.InArgs);
- if (!methodInfo.Name.StartsWith(“Get”))
- Log(“In Dynamic Proxy – After executing ‘{0}’ “,
- methodCall.MethodName);
- return new ReturnMessage(result, null, 0,
- methodCall.LogicalCallContext, methodCall);
- catch (Exception e)
- if (!methodInfo.Name.StartsWith(“Get”))
- Log(string.Format(
- “In Dynamic Proxy- Exception {0} executing ‘{1}'”, e),
- methodCall.MethodName);
- return new ReturnMessage(e, methodCall);
The program checks if the method starts with “Get.” If it does, the program doesn’t apply the aspect. This works, but the filtering code is repeated three times. Besides that, the filter is inside the proxy, which will make you change the class every time you want to change the proxy. You can improve this by creating an IsValidMethod predicate:
- private static bool IsValidMethod(MethodInfo methodInfo)
- return !methodInfo.Name.StartsWith(“Get”);
Now you need to make the change in only one place, but you still need to change the class every time you want to change the filter. One solution to this would be to expose the filter as a class property, so you can assign the responsibility of creating a filter to the caller. You can create a Filter property of type Predicate<MethodInfo> and use it to filter the data, as shown in Figure 15.
Figure 15 A Filtering Proxy
- class DynamicProxy : RealProxy
- private readonly T _decorated;
- private Predicate<MethodInfo> _filter;
- public DynamicProxy(T decorated)
- : base(typeof(T))
- _decorated = decorated;
- _filter = m => true;
- public Predicate<MethodInfo> Filter
- get { return _filter; }
- if (value == null)
- _filter = m => true;
- _filter = value;
- 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;
- if (_filter(methodInfo))
- Log(“In Dynamic Proxy – Before executing ‘{0}'”,
- methodCall.MethodName);
- var result = methodInfo.Invoke(_decorated, methodCall.InArgs);
- if (_filter(methodInfo))
- Log(“In Dynamic Proxy – After executing ‘{0}’ “,
- methodCall.MethodName);
- return new ReturnMessage(result, null, 0,
- methodCall.LogicalCallContext, methodCall);
- catch (Exception e)
- if (_filter(methodInfo))
- Log(string.Format(
- “In Dynamic Proxy- Exception {0} executing ‘{1}'”, e),
- methodCall.MethodName);
- return new ReturnMessage(e, methodCall);
The Filter property is initialized with Filter = m => true. That means there’s no filter active. When assigning the Filter property, the program verifies if the value is null and, if so, it resets the filter. In the Invoke method execution, the program checks the filter result and, if true, it applies the aspect. Now the proxy creation in the factory class looks like this:
- public class RepositoryFactory
- public static IRepository<T> Create<T>()
- var repository = new Repository<T>();
- var dynamicProxy = new DynamicProxy<irepository>(repository)
- Filter = m => !m.Name.StartsWith(“Get”)
- return dynamicProxy.GetTransparentProxy() as IRepository<T>;
The responsibility of creating the filter has been transferred to the factory.When you run the program, you should get something like Figure 16.
Figure 16 Output with a Filtered Proxy
Notice in Figure 16 that the last two methods, GetAll and GetById (represented by “Getting entities” and “Getting entity 1”) don’t have logging around them.You can enhance the class even further by exposing the aspects as events. That way, you don’t have to change the class every time you want to change the aspect. This is shown in Figure 17.
Figure 17 A Flexible Proxy
- class DynamicProxy : RealProxy
- private readonly T _decorated;
- private Predicate<MethodInfo> _filter;
- public event EventHandler<IMethodCallMessage> BeforeExecute;
- public event EventHandler<IMethodCallMessage> AfterExecute;
- public event EventHandler<IMethodCallMessage> ErrorExecuting;
- public DynamicProxy(T decorated)
- : base(typeof(T))
- _decorated = decorated;
- Filter = m => true;
- public Predicate<MethodInfo> Filter
- get { return _filter; }
- if (value == null)
- _filter = m => true;
- _filter = value;
- private void OnBeforeExecute(IMethodCallMessage methodCall)
- if (BeforeExecute != null)
- var methodInfo = methodCall.MethodBase as MethodInfo;
- if (_filter(methodInfo))
- BeforeExecute(this, methodCall);
- private void OnAfterExecute(IMethodCallMessage methodCall)
- if (AfterExecute != null)
- var methodInfo = methodCall.MethodBase as MethodInfo;
- if (_filter(methodInfo))
- AfterExecute(this, methodCall);
- private void OnErrorExecuting(IMethodCallMessage methodCall)
- if (ErrorExecuting != null)
- var methodInfo = methodCall.MethodBase as MethodInfo;
- if (_filter(methodInfo))
- ErrorExecuting(this, methodCall);
- public override IMessage Invoke(IMessage msg)
- var methodCall = msg as IMethodCallMessage;
- var methodInfo = methodCall.MethodBase as MethodInfo;
- OnBeforeExecute(methodCall);
- var result = methodInfo.Invoke(_decorated, methodCall.InArgs);
- OnAfterExecute(methodCall);
- return new ReturnMessage(
- result, null, 0, methodCall.LogicalCallContext, methodCall);
- catch (Exception e)
- OnErrorExecuting(methodCall);
- return new ReturnMessage(e, methodCall);
In Figure 17, three events, BeforeExecute, AfterExecute and ErrorExecuting, are called by the methods OnBeforeExecute, OnAfterExecute and OnErrorExecuting.These methods verify whether the event handler is defined and, if it is, they check if the called method passes the filter. If so, they call the event handler that applies the aspect. The factory class now becomes something like Figure 18.
Figure 18 A Repository Factory that Sets the Aspect Events and Filter
- public class RepositoryFactory
- private static void Log(string msg, object arg = null)
- Console.ForegroundColor = ConsoleColor.Red;
- Console.WriteLine(msg, arg);
- Console.ResetColor();
- public static IRepository<T> Create<T>()
- var repository = new Repository<T>();
- var dynamicProxy = new DynamicProxy<irepository>(repository);
- dynamicProxy.BeforeExecute += (s, e) => Log(
- “Before executing ‘{0}'”, e.MethodName);
- dynamicProxy.AfterExecute += (s, e) => Log(
- “After executing ‘{0}'”, e.MethodName);
- dynamicProxy.ErrorExecuting += (s, e) => Log(
- “Error executing ‘{0}'”, e.MethodName);
- dynamicProxy.Filter = m => !m.Name.StartsWith(“Get”);
- return dynamicProxy.GetTransparentProxy() as IRepository<T>;
Now you have a flexible proxy class, and you can choose the aspects to apply before executing, after executing or when there’s an error, and only for selected methods. With that, you can apply many aspects in your code with no repetition, in a simple way.
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:
- public override IMessage Invoke(IMessage msg)
- var methodCall = msg as IMethodCallMessage;
- var methodInfo = methodCall.MethodBase as MethodInfo;
- if (!methodInfo.CustomAttributes
- .Any(a => a.AttributeType == typeof (LogAttribute)))
- var result = methodInfo.Invoke(_decorated, methodCall.InArgs);
- return new ReturnMessage(result, null, 0,
- methodCall.LogicalCallContext, methodCall);
Besides that, the technique used by RealProxy (intercept code and allow the program to replace it) is powerful. For example, if you want to create a mocking framework, for creating generic mocks and stubs for testing, you can use the RealProxy class to intercept all calls and replace them with your own behavior, but that’s a subject for another article!
Bruno Sonnino is a Microsoft Most Valuable Professional (MVP) located in Brazil.He’s a developer, consultant, and author, having written five Delphi books, published in Portuguese by Pearson Education Brazil, and many articles for Brazilian and U.S. magazines and Web sites.
Thanks to the following Microsoft Research technical experts for reviewing this article: James McCaffrey, Carlos Suarez and Johan Verwey James McCaffrey works for Microsoft Research in Redmond, Wash. He has worked on several Microsoft products including Internet Explorer and Bing. He can be reached at jammc@microsoft.com .
Carlos Garcia Jurado Suarez is a research software engineer in Microsoft Research, where he’s worked in the Advanced Development Team and more recently the Machine Learning Group. Earlier, he was a developer in Visual Studio working on modeling tools such as the Class Designer.
![ppt_img[1]](https://sharepointsamurai.files.wordpress.com/2014/10/ppt_img1.gif)
![sap_integration_en_round[1]](https://sharepointsamurai.files.wordpress.com/2014/09/sap_integration_en_round1.jpg)
Security Note
.png "Output of the Program with No Logging")
.png "Execution of the Logging Program with a Decorator")
.png "Program Execution with Dynamic Proxy")
.png "Output of the Program Using Two Proxies")
.png "Output with a Filtered Proxy")
SharePoint Samurai 