Let us begin by defining some central AOP concepts. These terms are not Spring.NET-specific. Unfortunately, AOP terminology is not particularly intuitive. However, it would be even more confusing if Spring.NET used its own terminology.

Different advice types include:

Spring.NET provides a full range of advice types. We recommend that you use the least powerful advice type that can implement the required behaviour. For example, if you need only to update a cache with the return value of a method, you are better off implementing an after returning advice than an around advice, although an around advice can accomplish the same thing. Using the most specific advice type provides a simpler programming model with less potential for errors. For example, you don't need to invoke the proceed() method on the IMethodInvocation used for around advice, and hence can't fail to invoke it.

The pointcut concept is the key to AOP, distinguishing AOP from older technologies offering interception. Pointcuts enable advice to be targeted independently of the OO hierarchy. For example, an around advice providing declarative transaction management can be applied to a set of methods spanning multiple objects. Thus pointcuts provide the structural element of AOP.

Spring.NET AOP is implemented in pure C#. There is no need for a special compilation process - all weaving is done at runtime. Spring.NET AOP does not need to control or modify the way in which assemblies are loaded, nor does it rely on unmanaged APIs, and is thus suitable for use in any CLR environment.

Spring.NET currently supports interception of method invocations. Field interception is not implemented, although support for field interception could be added without breaking the core Spring.NET AOP APIs.

Field interception arguably violates OO encapsulation. We don't believe it is wise in application development.

Spring.NET provides classes to represent pointcuts and different advice types. Spring.NET uses the term advisor for an object representing an aspect, including both an advice and a pointcut targeting it to specific joinpoints.

Different advice types are IMethodInterceptor (from the AOP Alliance interception API); and the advice interfaces defined in the Spring.Aop namespace. All advices must implement the AopAlliance.Aop.IAdvice tag interface. Advices supported out the box are IMethodInterceptor ; IThrowsAdvice; IBeforeAdvice; and IAfterReturningAdvice. We'll discuss advice types in detail below.

Spring.NET provides a .NET translation of the Java interfaces defined by the AOP Alliance . Around advice must implement the AOP Alliance AopAlliance.Interceptr.IMethodInterceptor interface. Whilst there is wide support for the AOP Alliance in Java, Spring.NET is currently the only .NET AOP framework that makes use of these interfaces. In the short term, this will provide a consistent programming model for those doing development in both .NET and Java, and in the longer term, we hope to see more .NET projects adopt the AOP Alliance interfaces.

The aim of Spring.NET AOP support is not to provide a comprehensive AOP implementation on par with the functionality available in AspectJ. However, Spring.NET AOP provides an excellent solution to most problems in .NET applications that are amenable to AOP.

Thus, it is common to see Spring.NET's AOP functionality used in conjunction with a Spring.NET IoC container. AOP advice is specified using normal object definition syntax (although this allows powerful "autoproxying" capabilities); advice and pointcuts are themselves managed by Spring.NET IoC.

Spring.NET generates AOP proxies at runtime using classes from the System.Reflection.Emit namespace to create necessary IL code for the proxy class. This results in proxies that are very efficient and do not impose any restrictions on the inheritance hierarchy.

Another common approach to AOP proxy implementation in .NET is to use ContextBoundObject and the .NET remoting infrastructure as an interception mechanism. We are not very fond of ContextBoundObject approach because it requires classes that need to be proxied to inherit from the ContextBoundObject either directly or indirectly. In our opinion this an unnecessary restriction that influences how you should design your object model and also excludes applying AOP to "3rd party" classes that are not under your direct control. Context-bound proxies are also an order of magnitude slower than IL-generated proxies, due to the overhead of the context switching and .NET remoting infrastructure.

Spring.NET AOP proxies are also "smart" - in that because proxy configuration is known during proxy generation, the generated proxy can be optimized to invoke target methods via reflection only when necessary (i.e. when there are advices applied to the target method). In all other cases the target method will be called directly, thus avoiding performance hit caused by the reflective invocation.

Finally, Spring.NET AOP proxies will never return a raw reference to a target object. Whenever a target method returns a raw reference to a target object (i.e. "return this;"), AOP proxy will recognize what happened and will replace the return value with a reference to itself instead.

The current implementation of the AOP proxy generator uses object composition to delegate calls from the proxy to a target object, similar to how you would implement a classic Decorator pattern. This means that classes that need to be proxied have to implement one or more interfaces, which is in our opinion not only a less-intruding requirement than ContextBoundObject inheritance requirements, but also a good practice that should be followed anyway for the service classes that are most common targets for AOP proxies.

In a future release we will implement proxies using inheritance, which will allow you to proxy classes without interfaces as well and will remove some of the remaining raw reference issues that cannot be solved using composition-based proxies.

Spring.NET's pointcut model enables pointcut reuse independent of advice types. It's possible to target different advice using the same pointcut.

The Spring.Aop.IPointcut interface is the central interface, used to target advices to particular types and methods. The complete interface is shown below:

public interface IPointcut
{
    ITypeFilter TypeFilter { get; }

    IMethodMatcher MethodMatcher { get; }
}

Splitting the IPointcut interface into two parts allows reuse of type and method matching parts, and fine-grained composition operations (such as performing a "union" with another method matcher).

The ITypeFilter interface is used to restrict the pointcut to a given set of target classes. If the Matches() method always returns true, all target types will be matched:

public interface ITypeFilter
{
    bool Matches(Type type);
}

The IMethodMatcher interface is normally more important. The complete interface is shown below:

public interface IMethodMatcher
{
    bool IsRuntime { get; }

    bool Matches(MethodInfo method, Type targetType);

    bool Matches(MethodInfo method, Type targetType, object[] args);
}

The Matches(MethodInfo, Type) method is used to test whether this pointcut will ever match a given method on a target type. This evaluation can be performed when an AOP proxy is created, to avoid the need for a test on every method invocation. If the 2-argument matches method returns true for a given method, and the IsRuntime property for the IMethodMatcher returns true, the 3-argument matches method will be invoked on every method invocation. This enables a pointcut to look at the arguments passed to the method invocation immediately before the target advice is to execute.

Most IMethodMatchers are static, meaning that their IsRuntime property returns false. In this case, the 3-argument Matches method will never be invoked.

Whenever possible, try to make pointcuts static... this allows the AOP framework to cache the results of pointcut evaluation when an AOP proxy is created.

Spring.NET supports operations on pointcuts: notably, union and intersection.

Union means the methods that either pointcut matches.

Intersection means the methods that both pointcuts match.

Union is usually more useful.

Pointcuts can be composed using the static methods in the Spring.Aop.Support.Pointcuts class, or using the ComposablePointcut class in the same namespace.

Spring.NET provides several convenient pointcut implementations. Some can be used out of the box; others are intended to be subclassed in application-specific pointcuts.

<object id="settersAndAbsquatulatePointcut" 
    type="Spring.Aop.Support.SdkRegularExpressionMethodPointcut, Spring.Aop">
    <property name="patterns">
        <list>
            <value>.*set.*</value>
            <value>.*absquatulate</value>
        </list>
    </property>
</object>

<object id="settersAndAbsquatulateAdvisor" 
    type="Spring.Aop.Support.RegularExpressionMethodPointcutAdvisor, Spring.Aop">
    <property name="advice">
        <ref local="objectNameOfAopAllianceInterceptor"/>
    </property>
    <property name="patterns">
        <list>
            <value>.*set.*</value>
            <value>.*absquatulate</value>
        </list>
    </property>
</object>

<object id="cachePointcut" type="Spring.Aop.Support.AttributeMatchMethodPointcut, Spring.Aop"> 
    <property name="Attribute" value="Spring.Attributes.CacheAttribute, Spring.Core"/>        
</object>

<object id="cacheAspect" type="Spring.Aop.Support.DefaultPointcutAdvisor, Spring.Aop"> 
  <property name="Pointcut"> 
      <object type="Spring.Aop.Support.AttributeMatchMethodPointcut, Spring.Aop"> 
          <property name="Attribute" value="Spring.Attributes.CacheAttribute, Spring.Core"/>        
      </object> 
  </property> 
  <property name="Advice" ref="aspNetCacheAdvice"/> 
</object> 

<object id="AspNetCacheAdvice" type="Spring.Aop.Support.AttributeMatchMethodPointcutAdvisor, Spring.Aop"> 
   <property name="advice"> 
      <object type="Aspect.AspNetCacheAdvice, Aspect"/> 
   </property> 
   <property name="attribute" value="Framework.AspNetCacheAttribute, Framework" /> 
</object>

13.2.3.2. Dynamic Pointcuts

Dynamic pointcuts are costlier to evaluate than static pointcuts. They take into account method arguments, as well as static information. This means that they must be evaluated with every method invocation; the result cannot be cached, as arguments will vary.

The main example is the control flow pointcut.

13.2.3.2.1. Control Flow Pointcuts

Spring.NET control flow pointcuts are conceptually similar to AspectJ cflow pointcuts, although less powerful. (There is currently no way to specify that a pointcut executes below another pointcut.). A control flow pointcut is dynamic because it is evaluated against the current call stack for each method invocation. For example, if method ClassA.A() calls ClassB.B() then the execution of ClassB.B() has occurred in ClassA.A()'s control flow. A control flow pointcut allows advice to be applied to the method ClassA.A() but only when called from ClassB.B() and not when ClassA.A() is executed from another call stack. Control flow pointcuts are specified using the Spring.Aop.Support.ControlFlowPointcut class.

	Note
	Control flow pointcuts are significantly more expensive to evaluate at runtime than even other dynamic pointcuts.

When using control flow point cuts some attention should be paid to the fact that at runtime the JIT compiler can inline the methods, typically for increased performance, but with the consequence that the method no longer appears in the current call stack. This is because inlining takes the callee's IL code and inserts it into the caller's IL code effectively removing the method call. The information returned from System.Diagnostics.StackTrace, used in the implementation of ControlFlowPointcut is subject to these optimizations and therefore a control flow pointcut will not match if the method has been inlined.

Generally speaking, a method will be a candidate for inlining when its code is 'small', just a few lines of code (less than 32 bytes of IL). For some interesting reading on this process read David Notario's blog entries (JIT Optimizations I and JIT Optimizations II). Additionally, when an assembly is compiled with a Release configuration the assembly metadata instructs the CLR to enable JIT optimizations. When compiled with a Debug configuration the CLR will disable (some?) these optimizations. Empirically, method inlining is turned off in a Debug configuration.

The way to ensure that your control flow pointcut will not be overlooked because of method inlining is to apply the System.Runtime.CompilerServices.MethodImplAttribute attribute with the value MethodImplOptions.NoInlining. In this (somewhat artificial) simple example, if the code is compiled in release mode it will not match a control flow pointcut for the method "GetAge".

public int GetAge(IPerson person)
{
    return person.GetAge();
}

However, applying the attributes as shown below will prevent the method from being inlined even in a release build.

[MethodImpl(MethodImplOptions.NoInlining)] 
public int GetAge(IPerson person)
{
    return person.GetAge();
}

Because pointcuts in Spring.NET are .NET types, rather than language features (as in AspectJ) it is possible to declare custom pointcuts, whether static or dynamic. However, there is no support out of the box for the sophisticated pointcut expressions that can be coded in the AspectJ syntax. However, custom pointcuts in Spring.NET can be as arbitrarily complex as any object model.

Spring.NET provides useful pointcut superclasses to help you to implement your own pointcuts.

Because static pointcuts are the most common and generally useful pointcut type, you'll probably subclass StaticMethodMatcherPointcut, as shown below. This requires you to implement just one abstract method (although it is possible to override other methods to customize behaviour):

public class TestStaticPointcut : StaticMethodMatcherPointcut {

    public override bool Matches(MethodInfo method, Type targetType) {
        // return true if custom criteria match
    }
}

Spring.NET advices can be shared across all advised objects, or unique to each advised object. This corresponds to per-class or per-instance advice.

Per-class advice is used most often. It is appropriate for generic advice such as transaction advisors. These do not depend on the state of the proxied object or add new state; they merely act on the method and arguments.

Per-instance advice is appropriate for introductions, to support mixins. In this case, the advice adds state to the proxied object.

It's possible to use a mix of shared and per-instance advice in the same AOP proxy.

Spring.NET provides several advice types out of the box, and is extensible to support arbitrary advice types. Let us look at the basic concepts and standard advice types.

public interface IMethodInterceptor : IInterceptor
{
    object Invoke(IMethodInvocation invocation);
}

public class DebugInterceptor : IMethodInterceptor {

    public object Invoke(IMethodInvocation invocation) {
        Console.WriteLine("Before: invocation=[{0}]", invocation);
        object rval = invocation.Proceed();
        Console.WriteLine("Invocation returned");
        return rval;
    }
}

public interface IMethodBeforeAdvice : IBeforeAdvice
{
    void Before(MethodInfo method, object[] args, object target);
}

public class CountingBeforeAdvice : IMethodBeforeAdvice {

    private int count;
    
    public void Before(MethodInfo method, object[] args, object target) {
        ++count;
    }

    public int Count  {
        get { return count; }
    }
}

13.3.2.3. Throws advice

Throws advice is invoked after the return of the joinpoint if the joinpoint threw an exception. The Spring.Aop.IThrowsAdvice interface does not contain any methods: it is a tag interface identifying that the implementing advice object implements one or more typed throws advice methods. These throws advice methods must be of the form:

AfterThrowing([MethodInfo method, Object[] args, Object target], Exception subclass)

Throws-advice methods must be named 'AfterThrowing'. The return value will be ignored by the Spring.NET AOP framework, so it is typically void. With regard to the method arguments, only the last argument is required. Thus there are exactly one or four arguments, depending on whether the advice method is interested in the method, method arguments and the target object.

The following method snippets show examples of throws advice.

This advice will be invoked if a RemotingException is thrown (including subclasses):

public class RemoteThrowsAdvice : IThrowsAdvice {

    public void AfterThrowing(RemotingException ex) {
        // Do something with remoting exception
    }
}

The following advice is invoked if a SqlException is thrown. Unlike the above advice, it declares 4 arguments, so that it has access to the invoked method, method arguments and target object:

public class SqlExceptionThrowsAdviceWithArguments : IThrowsAdvice {

    public void AfterThrowing(MethodInfo method, object[] args, object target, SqlException ex) {
        // Do something will all arguments
    }
}

The final example illustrates how these two methods could be used in a single class, which handles both RemotingException and SqlException. Any number of throws advice methods can be combined in a single class, as can be seen in the following example.

public class CombinedThrowsAdvice : IThrowsAdvice {

    public void AfterThrowing(RemotingException ex)  {
        // Do something with remoting exception
    }
 
    public void AfterThrowing(MethodInfo method, object[] args, object target, SqlException ex) {
        // Do something will all arguments
    }
}

Finally, it is worth stating that throws advice is only applied to the actual exception being thrown. What does this mean? Well, it means that if you have defined some throws advice that handles RemotingExceptions, the applicable AfterThrowing method will only be invoked if the type of the thrown exception is RemotingException... if a RemotingException has been thrown and subsequently wrapped inside another exception before the exception bubbles up to the throws advice interceptor, then the throws advice that handles RemotingExceptions will never be called. Consider a business method that is advised by throws advice that handles RemotingExceptions; if during the course of a method invocation said business method throws a RemoteException... and subsequently wraps said RemotingException inside a business-specific BadConnectionException (see the code snippet below) before throwing the exception, then the throws advice will never be able to respond to the RemotingException... because all the throws advice sees is a BadConnectionException. The fact that the RemotingException is wrapped up inside the BadConnectionException is immaterial.

public void BusinessMethod()
    {
        try
        {
            // do some business operation...
        }
        catch (RemotingException ex)
        {
            throw new BadConnectionException("Couldn't connect.", ex);
        }
    }

	Note
	Please note that throws advice can be used with any pointcut.

13.3.2.4. After Returning advice

An after returning advice in Spring.NET must implement the Spring.Aop.IAfterReturningAdvice interface, shown below:

public interface IAfterReturningAdvice : IAdvice
{
  void AfterReturning(object returnValue, MethodBase method, object[] args, object target);
}

An after returning advice has access to the return value (which it cannot modify), invoked method, methods arguments and target.

The following after returning advice counts all successful method invocations that have not thrown exceptions:

public class CountingAfterReturningAdvice : IAfterReturningAdvice {
    private int count;

    public void AfterReturning(object returnValue, MethodBase m, object[] args, object target) {
        ++count;
    }

    public int Count  {
        get { return count; }
    }
}

This advice doesn't change the execution path. If it throws an exception, this will be thrown up the interceptor chain instead of the return value.

	Note
	Please note that after-returning advice can be used with any pointcut.

13.3.2.6. Introduction advice

Spring.NET allows you to add new methods and properties to an advised class. This would typically be done when the functionality you wish to add is a crosscutting concern and want to introduce this functionality as a change to the static structure of the class hierarchy. For example, you may want to cast objects to the introduction interface in your code. Introductions are also a means to emulate multiple inheritance.

Introduction advice is defined by using a normal interface declaration that implements the tag interface IAdvice.

	Note
	The need for implementing this marker interface will likely be removed in future versions.

As an example, consider the interface IAuditable that describes the last modified time of an object.

public interface IAuditable : IAdvice
{
    DateTime LastModifiedDate
    {
        get;
        set;
    }
}

where

public interface IAdvice
{        
}

Access to the advised object can be obtained by implementing the interface ITargetAware

public interface ITargetAware
{
  IAopProxy TargetProxy
  {
    set;
  }
}

with the IAopProxy reference providing a layer of indirection through which the advised object can be accessed.

public interface IAopProxy
{
  object GetProxy();
}

A simple class that demonstrates this functionality is shown below.

public interface IAuditable : IAdvice, ITargetAware
{
    DateTime LastModifiedDate
    {
        get;
        set;
    }
}

A class that implements this interface is shown below.

public class AuditableMixin : IAuditable
{
    private DateTime date;
    private IAopProxy targetProxy;

    public AuditableMixin()
    {
      date = new DateTime();
    }

    public DateTime LastModifiedDate
    {
       get { return date; }
       set { date = value; }
    }

    public IAopProxy TargetProxy
    {
       set { targetProxy = value; }
    }
}

Introduction advice is not associated with a pointcut, since it applies at the class and not the method level. As such, introductions use their own subclass of the interface IAdvisor, namely IIntroductionAdvisor, to specify the types that the introduction can be applied to.

public interface IIntroductionAdvisor : IAdvisor
{
    ITypeFilter TypeFilter { get; }
    
    Type[] Interfaces { get; }

    void ValidateInterfaces();
}

The TypeFilter property returns the filter that determines which target classes this introduction should apply to.

The Interfaces property returns the interfaces introduced by this advisor.

The ValidateInterfaces() method is used internally to see if the introduced interfaces can be implemented by the introduction advice.

Spring.NET provides a default implementation of this interface (the DefaultIntroductionAdvisor class) that should be sufficient for the majority of situations when you need to use introductions. The most simple implementation of an introduction advisor is a subclass that simply passes a new instance the base constructor. Passing a new instance is important since we want a new instance of the mixin classed used for each advised object.

public class AuditableAdvisor : DefaultIntroductionAdvisor
{
  public AuditableAdvisor() : base(new AuditableMixin())
  {
  }
}

Other constructors let you explicitly specify the interfaces of the class that will be introduced. See the SDK documentation for more details.

We can apply this advisor Programatically, using the IAdvised.AddIntroduction(), method, or (the recommended way) in XML configuration using the IntroductionNames property on ProxyFactoryObject, which will be discussed later.

Unlike the AOP implementation in the Spring Framework for Java, introduction advice in Spring.NET is not implemented as a specialized type of interception advice. The advantage of this approach is that introductions are not kept in the interceptor chain, which allows some significant performance optimizations. When a method is called that has no interceptors, a direct call is used instead of reflection regardless of whether the target method is on the target object itself or one of the introductions. This means that introduced methods perform the same as target object methods, which could be useful for adding introductions to fine grained objects. The disadvantage is that if the mixin functionality would benefit from having access to the calling stack, it is not available. Introductions with this functionality will be addressed in a future version of Spring.NET AOP.

The ProxyFactoryObject, like other Spring.NET IFactoryObject implementations, introduces a level of indirection. If you define a ProxyFactoryObject with name foo, what objects referencing foo see is not the ProxyFactoryObject instance itself, but an object created by the ProxyFactoryObject's implementation of the GetObject() method. This method will create an AOP proxy wrapping a target object.

One of the most important benefits of using a ProxyFactoryObject or other IoC-aware classes that create AOP proxies, is that it means that advice and pointcuts can also be managed by IoC. This is a powerful feature, enabling certain approaches that are hard to achieve with other AOP frameworks. For example, an advice may itself reference application objects (besides the target, which should be available in any AOP framework), benefiting from all the pluggability provided by Dependency Injection.

Like most IFactoryObject implementations provided with Spring.NET, the ProxyFactoryObject is itself a Spring.NET configurable object. Its properties are used to:

Some key properties are inherited from the Spring.Aop.Framework.ProxyConfig class: this class is the superclass for all AOP proxy factories in Spring.NET. Some of the key properties include:

Other properties specific to the ProxyFactoryObject class include:

Let's look at a simple example of ProxyFactoryObject in action. This example involves:

<object id="personTarget" type="MyCompany.MyApp.Person, MyCompany">
    <property name="name" value="Tony"/>
    <property name="age" value="51"/>
</object>

<object id="myCustomInterceptor" type="MyCompany.MyApp.MyCustomInterceptor, MyCompany">
    <property name="customProperty" value="configuration string"/>
</object>

<object id="debugInterceptor" type="Spring.Aop.Advice.DebugAdvice, Spring.Aop">
</object>

<object id="person" type="Spring.Aop.Framework.ProxyFactoryObject, Spring.Aop">
    
    <property name="proxyInterfaces" value="MyCompany.MyApp.IPerson"/>

    <property name="target" ref="personTarget"/>

    <property name="interceptorNames">
        <list>
            <value>debugInterceptor</value>
            <value>myCustomInterceptor</value>
        </list>
    </property>

</object>

Note that the InterceptorNames property takes a list of strings: the object names of the interceptor or advisors in the current context. Advisors, interceptors, before, after returning and throws advice objects can be used. The ordering of advisors is significant.

You might be wondering why the list doesn't hold object references. The reason for this is that if the ProxyFactoryObject's singleton property is set to false, it must be able to return independent proxy instances. If any of the advisors is itself a prototype, an independent instance would need to be returned, so it's necessary to be able to obtain an instance of the prototype from the context; holding a reference isn't sufficient.

The "person" object definition above can be used in place of an IPerson implementation, as follows:

IPerson person = (IPerson) factory.GetObject("person");

Other objects in the same IoC context can express a strongly typed dependency on it, as with an ordinary .NET object:

<object id="personUser" type="MyCompany.MyApp.PersonUser, MyCompany">
    <property name="person" ref="person"/>
</object>

The PersonUser class in this example would expose a property of type IPerson. As far as it's concerned, the AOP proxy can be used transparently in place of a "real" person implementation. However, its type would be a proxy type. It would be possible to cast it to the IAdvised interface (discussed below).

It's possible to conceal the distinction between target and proxy using an anonymous inline object, as follows. (for more information on inline objects see Section 5.3.2.3, “Inner objects”.) Only the ProxyFactoryObject definition is different; the advice is included only for completeness:

<object id="myCustomInterceptor" type="MyCompany.MyApp.MyCustomInterceptor, MyCompany">
    <property name="customProperty" value="configuration string"/>
</object>

<object id="debugInterceptor" type="Spring.Aop.Advice.DebugAdvice, Spring.Aop">
</object>

<object id="person" type="Spring.Aop.Framework.ProxyFactoryObject, Spring.Aop">
    
    <property name="proxyInterfaces" value="MyCompany.MyApp.IPerson"/>

    <property name="target">
      <!-- Instead of using a reference to target, just use an inline object -->
      <object type="MyCompany.MyApp.Person, MyCompany">
        <property name="name" value="Tony"/>
        <property name="age" value="51"/>
      </object>
    </property>

    <property name="interceptorNames">
        <list>
            <value>debugInterceptor</value>
            <value>myCustomInterceptor</value>
        </list>
    </property>

</object>

This has the advantage that there's only one object of type Person: useful if we want to prevent users of the application context obtaining a reference to the un-advised object, or need to avoid any ambiguity with Spring IoC autowiring. There's also arguably an advantage in that the ProxyFactoryObject definition is self-contained. However, there are times when being able to obtain the un-advised target from the factory might actually be an advantage: for example, in certain test scenarios.

Let's look at an example of configuring the proxy objects retrieved from ProxyFactoryObject.

          <!-- create the object to reference -->
          <object id="RealObjectTarget" type="MyRealObject" singleton="false"/>
          <!-- create the proxied object for everyone to use-->
          <object id="MyObject" type="Spring.Aop.Framework.ProxyFactoryObject, Spring.Aop">
          <property name="proxyInterfaces" value="MyInterface" />
          <property name="isSingleton" value="false"/>
          <property name="targetName" value="RealObjectTarget" />
          </object>
        

If you are using a prototype as the target you must set the TargetName property with the name/object id of your object and not use the property Target with a reference to that object. This will then allow a new proxy to be created around a new prototype target instance.

Consider the above Spring.Net object configuration. Notice that the IsSingleton property of the ProxyFactoryObject instance is set to false. This means that each proxy object will be unique. Thus, you can configure each proxy object with its' own individual advice(s) using the following syntax

// Will return un-advised instance of proxy object
MyInterface myProxyObject1 = (MyInterface)ctx.GetObject("MyObject");

// myProxyObject1 instance now has an advice attached to it.
IAdvised advised = (IAdvised)myProxyObject1;
advised.AddAdvice( new DebugAdvice() );

// Will return a new, un-advised instance of proxy object
MyInterface myProxyObject2 = (MyInterface)ctx.GetObject("MyObject");

What if you need to proxy a class, rather than one or more interfaces?

Imagine that in our example above, there was no IPerson interface, rather we needed to advise a class called Person that didn't implement any business interface. In this case the ProxyFactoryObject will proxy all public virtual methods and properties if no interfaces are explicitly specified or if no interfaces are found to be present on the target object. One can configure Spring.NET to force the use of class proxies, rather than interface proxies, by setting the ProxyTargetType property on the ProxyFactoryObject above to true.

Class proxying works by generating a subclass of the target class at runtime. Spring.NET configures this generated subclass to delegate method calls to the original target: the subclass is used to implement the Decorator pattern, weaving in the advice.

Class proxying should generally be transparent to users. However, there is an important issue to consider: Non-virtual methods can't be advised, as they can't be overridden. This may be a limiting factor when using existing code as it has been common practice not to declare methods as virtual by default.

Especially when defining transactional proxies, if you do not make use of the transaction namespace, you may end up with many similar proxy definitions. The use of parent and child object definitions, along with inner object definitions, can result in much cleaner and more concise proxy definitions.

First a parent, template, object definition is created for the proxy:

<object id="txProxyTemplate"  abstract="true"
            type="Spring.Transaction.Interceptor.TransactionProxyFactoryObject, Spring.Data">
        
        <property name="PlatformTransactionManager" ref="adoTransactionManager"/>
        <property name="TransactionAttributes">
            <name-values>
                <add key="*" value="PROPAGATION_REQUIRED"/>
            </name-values>
        </property>
    </object>

This will never be instantiated itself, so may actually be incomplete. Then each proxy which needs to be created is just a child object definition, which wraps the target of the proxy as an inner object definition, since the target will never be used on its own anyway.

<object name="testObjectManager" parent="txProxyTemplate">
        <property name="Target">
            <object type="Spring.Data.TestObjectManager, Spring.Data.Integration.Tests">
                <property name="TestObjectDao" ref="testObjectDao"/>
            </object>
        </property> 
</object>

It is of course possible to override properties from the parent template, such as in this case, the transaction propagation settings:

<object name="testObjectManager" parent="txProxyTemplate">
        <property name="Target">
            <object type="Spring.Data.TestObjectManager, Spring.Data.Integration.Tests">
                <property name="TestObjectDao" ref="testObjectDao"/>
            </object>
        </property> 
        <property name="TransactionAttributes">
            <name-values>
                <add key="Save*" value="PROPAGATION_REQUIRED"/>
                <add key="Delete*" value="PROPAGATION_REQUIRED"/>
                <add key="Find*" value="PROPAGATION_REQUIRED,readonly"/>
            </name-values>
        </property>
</object>

Note that in the example above, we have explicitly marked the parent object definition as abstract by using the abstract attribute, as described previously, so that it may not actually ever be instantiated. Application contexts (but not simple object factories) will by default pre-instantiate all singletons. It is therefore important (at least for singleton object) that if you have a (parent) object definition which you intend to use only as a template, and this definition specifies a class, you must make sure to set the abstract attribute to true, otherwise the application context will actually try to pre-instantiate it.

There is an important limitation in the inheritance based proxy as described above, all methods that manipulate the state of the object should be declared as virtual. Otherwise some method invocations get directed to the private 'target' field member and others to the base class. Winform objects are an example of a case where this approach does not apply. To address this limitation, a new post-processing mechanism was introduced in version 1.2 that creates a proxy type without the private 'target' field. Interception advice is added directly in the method body before invoking the base class method.

To use this inheritance based proxy described in the note above, declare an instance of the InheritanceBasedAopConfigurer, and IObjectFactoryPostProcessor, in your configuration file. Here is an example:

<object type="Spring.Aop.Framework.AutoProxy.InheritanceBasedAopConfigurer, Spring.Aop">
  <property name="ObjectNames">
      <list>
          <value>Form*</value>
          <value>Control*</value>
      </list>
  </property>
  <property name="InterceptorNames">
      <list>
          <value>debugInterceptor</value>
      </list>
  </property>
</object>

<object id="debugInterceptor" type="AopPlay.DebugInterceptor, AopPlay"/>

This configuration style is similar to the autoproxy by name approach described here and is particularly appropriate when you want to apply advice to Winform classes.

The namespace Spring.Aop.Framework.AutoProxy provides generic autoproxy infrastructure, should you choose to write your own autoproxy implementations, as well as several out-of-the-box implementations. Two implementations are provided, ObjectNameAutoProxyCreator and DefaultAdvisorAutoProxyCreator. These are discussed in the following sections.

public enum Language
{
    English = 1,
    Portuguese = 2,
    Italian = 3
}


public interface IHelloWorldSpeaker
{
   void SayHello();
}


public class HelloWorldSpeaker : IHelloWorldSpeaker
{
    private Language language;

    public Language Language
    {
        set { language = value; }
        get { return language; }
    }

    public void SayHello()
    {
        switch (language)
        {
            case Language.English:
                Console.WriteLine("Hello World!");
                break;
            case Language.Portuguese:
                Console.WriteLine("Oi Mundo!");
                break;
            case Language.Italian:
                Console.WriteLine("Ciao Mondo!");
                break;
        }
    }
}


public class DebugInterceptor : IMethodInterceptor
{
    public object Invoke(IMethodInvocation invocation)
    {
        Console.WriteLine("Before: " + invocation.Method.ToString());
        object rval = invocation.Proceed();
        Console.WriteLine("After:  " + invocation.Method.ToString());
        return rval;
    }

}

<object id="ProxyCreator" type="Spring.Aop.Framework.AutoProxy.ObjectNameAutoProxyCreator, Spring.Aop">
  <property name="ObjectNames">
      <list>
          <value>English*</value>
          <value>PortugeseSpeaker</value>
      </list>
  </property>
  <property name="InterceptorNames">
      <list>
          <value>debugInterceptor</value>
      </list>
  </property>
</object>

<object id="debugInterceptor" type="AopPlay.DebugInterceptor, AopPlay"/>

<object id="EnglishSpeakerOne" type="AopPlay.HelloWorldSpeaker, AopPlay">
  <property name="Language" value="English"/>
</object>

<object id="EnglishSpeakerTwo" type="AopPlay.HelloWorldSpeaker, AopPlay">
  <property name="Language" value="English"/>
</object>

<object id="PortugeseSpeaker" type="AopPlay.HelloWorldSpeaker, AopPlay">
  <property name="Language" value="Portuguese"/>
</object>
            
<object id="ItalianSpeakerOne" type="AopPlay.HelloWorldSpeaker, AopPlay">
  <property name="Language" value="Italian"/>
</object>

IApplicationContext ctx = ContextRegistry.GetContext();
IDictionary speakerDictionary = ctx.GetObjectsOfType(typeof(IHelloWorldSpeaker));
foreach (DictionaryEntry entry in speakerDictionary)
{
    string name = (string)entry.Key;
    IHelloWorldSpeaker worldSpeaker = (IHelloWorldSpeaker)entry.Value;
    Console.Write(name + " says; ");
    worldSpeaker.SayHello(); 
}

ItalianSpeakerOne says; Ciao Mondo!
EnglishSpeakerTwo says; Before: Void SayHello()
Hello World!
After:  Void SayHello()
PortugeseSpeaker says; Before: Void SayHello()
Oi Mundo!
After:  Void SayHello()
EnglishSpeakerOne says; Before: Void SayHello()
Hello World!
After:  Void SayHello()

public interface ISpeakerDao
{
    IList FindAll();

    IHelloWorldSpeaker Save(IHelloWorldSpeaker speaker);
}

public class SpeakerDao : ISpeakerDao
{
    public System.Collections.IList FindAll()
    {
        Console.WriteLine("Finding speakers...");
	// just a demo...fake the retrieval.
        Thread.Sleep(10000);
        HelloWorldSpeaker speaker = new HelloWorldSpeaker();
        speaker.Language = Language.Portuguese;

        IList list = new ArrayList();
        list.Add(speaker);
        return list;
    }

    public IHelloWorldSpeaker Save(IHelloWorldSpeaker speaker)
    {
        Console.WriteLine("Saving speaker...");
        // just a demo...not really saving...
        return speaker;
    }

}

<object id="SpeachAdvisor" type="Spring.Aop.Support.RegularExpressionMethodPointcutAdvisor, Spring.Aop">
    
    <property name="advice" ref="debugInterceptor"/>            
    <property name="patterns">
        <list>
            <value>.*Say.*</value>
        </list>
    </property>
    
</object>

<object id="AdoAdvisor" type="Spring.Aop.Support.RegularExpressionMethodPointcutAdvisor, Spring.Aop">
    
    <property name="advice" ref="timingInterceptor"/>            
    <property name="patterns">
        <list>
            <value>.*Find.*</value>
        </list>
    </property>
    
</object>

// Advice
<object id="debugInterceptor" type="AopPlay.DebugInterceptor, AopPlay"/>

<object id="timingInterceptor" type="AopPlay.TimingInterceptor, AopPlay"/>

// Speaker DAO Object - has 'FindAll' Method.
<object id="speakerDao" type="AopPlay.SpeakerDao, AopPlay"/>

// HelloWorldSpeaker objects as previously listed.

<object id="ProxyCreator" type="Spring.Aop.Framework.AutoProxy.DefaultAdvisorAutoProxyCreator, Spring.Aop"/>

IApplicationContext ctx = ContextRegistry.GetContext();
IDictionary speakerDictionary = ctx.GetObjectsOfType(typeof(IHelloWorldSpeaker));
foreach (DictionaryEntry entry in speakerDictionary)
{
    string name = (string)entry.Key;
    IHelloWorldSpeaker worldSpeaker = (IHelloWorldSpeaker)entry.Value;
    Console.Write(name + " says; ");
    worldSpeaker.SayHello(); 
}
ISpeakerDao dao = (ISpeakerDao)ctx.GetObject("speakerDao");
IList speakerList = dao.FindAll();
IHelloWorldSpeaker speaker = dao.Save(new HelloWorldSpeaker());

ItalianSpeakerOne says; Before: Void SayHello()
Ciao Mondo!
After:  Void SayHello()
EnglishSpeakerTwo says; Before: Void SayHello()
Hello World!
After:  Void SayHello()
PortugeseSpeaker says; Before: Void SayHello()
Oi Mundo!
After:  Void SayHello()
EnglishSpeakerOne says; Before: Void SayHello()
Hello World!
After:  Void SayHello()
Finding speakers...
Elapsed time = 00:00:10.0154745
Saving speaker...

A particularly important type of autoproxying is driven by attributes. The programming model is similar to using Enterprise Services with ServicedComponents.

In this case, you use the DefaultAdvisorAutoProxyCreator, in combination with Advisors that understand attributes. The Advisor pointcut is identified by the presence of .NET attribute in the source code and it is configured via the data and/or methods of the attribute. This is a powerful alternative to identifying the advisor pointcut and advice configuration through traditional property configuration, either programmatic or through XML based configuration.

Several of the aspect provided with Spring use attribute driven autoproxying. The most prominent example is Transaction support.

The org.Spring.NETframework.aop.target.HotSwappableTargetSource exists to allow the target of an AOP proxy to be switched while allowing callers to keep their references to it.

Changing the target source's target takes effect immediately. The HotSwappableTargetSource is thread safe.

You can change the target via the swap() method on HotSwappableTargetSource as follows:

HotSwappableTargetSource swapper = 
    (HotSwappableTargetSource) objectFactory.GetObject("swapper");
object oldTarget = swapper.swap(newTarget);

The XML definitions required look as follows:

<object id="initialTarget" type="MyCompany.OldTarget, MyCompany">
</object>

<object id="swapper" 
    type="Spring.Aop.Target.HotSwappableTargetSource, Spring.Aop">
    <constructor-arg><ref local="initialTarget"/></constructor-arg>
</object>

<object id="swappable" 
    type="Spring.Aop.Framework.ProxyFactoryObject, Spring.Aop"
>
    <property name="targetSource">
        <ref local="swapper"/>
    </property>
</object>

The above swap() call changes the target of the swappable object. Clients who hold a reference to that object will be unaware of the change, but will immediately start hitting the new target.

Although this example doesn't add any advice--and it's not necessary to add advice to use a TargetSource--of course any TargetSource can be used in conjunction with arbitrary advice.

Using a pooling target source provides a programming model in which a pool of identical instances is maintained, with method invocations going to free objects in the pool.

A crucial difference between Spring.NET pooling and pooling in .NET Enterprise Services pooling is that Spring.NET pooling can be applied to any POCO. (Plain old CLR object). As with Spring.NET in general, this service can be applied in a non-invasive way.

Spring.NET provides out-of-the-box support using a pooling implementation based on Jakarta Commons Pool 1.1, which provides a fairly efficient pooling implementation. It's also possible to subclass Spring.Aop.Target.AbstractPoolingTargetSource to support any other pooling API.

Sample configuration is shown below:

<object id="businessObjectTarget" type="MyCompany.MyBusinessObject, MyCompany" singleton="false">
    ... properties omitted
</object>

<object id="poolTargetSource" type="Spring.Aop.Target.SimplePoolTargetSource, Spring.Aop">
    <property name="targetObjectName" value="businessObjectTarget"/>
    <property name="maxSize" value="25"/>
</object>

<object id="businessObject" type="Spring.Aop.Framework.ProxyFactoryObject, Spring.Aop">
    <property name="targetSource" ref="poolTargetSource"/>
    <property name="interceptorNames" value="myInterceptor"/>
</object>

Note that the target object--"businessObjectTarget" in the example--must be a prototype. This allows the PoolingTargetSource implementation to create new instances of the target to grow the pool as necessary. See the SDK documentation for AbstractPoolingTargetSource and the concrete subclass you wish to use for information about it's properties: maxSize is the most basic, and always guaranteed to be present.

In this case, "myInterceptor" is the name of an interceptor that would need to be defined in the same IoC context. However, it isn't necessary to specify interceptors to use pooling. If you want only pooling, and no other advice, don't set the interceptorNames property at all.

It's possible to configure Spring.NET so as to be able to cast any pooled object to the Spring.Aop.Target.PoolingConfig interface, which exposes information about the configuration and current size of the pool through an introduction. You'll need to define an advisor like this:

<object id="poolConfigAdvisor" 
    type="Spring.Object.Factory.Config.MethodInvokingFactoryObject, Spring.Aop">
    <property name="target" ref="poolTargetSource" />
    <property name="targetMethod" value="getPoolingConfigMixin" />
</object>

This advisor is obtained by calling a convenience method on the AbstractPoolingTargetSource class, hence the use of MethodInvokingFactoryObject. This advisor's name ('poolConfigAdvisor' here) must be in the list of interceptor names in the ProxyFactoryObject exposing the pooled object.

The cast will look as follows:

PoolingConfig conf = (PoolingConfig) objectFactory.GetObject("businessObject");
Console.WriteLine("Max pool size is " + conf.getMaxSize());

Pooling stateless service objects is not usually necessary. We don't believe it should be the default choice, as most stateless objects are naturally threadsafe, and instance pooling is problematic if resources are cached.

Simpler pooling is available using autoproxying. It's possible to set the TargetSources used by any autoproxy creator.

Setting up a "prototype" target source is similar to a pooling TargetSource. In this case, a new instance of the target will be created on every method invocation. Although the cost of creating a new object may not be high, the cost of wiring up the new object (satisfying its IoC dependencies) may be more expensive. Thus you shouldn't use this approach without very good reason.

To do this, you could modify the poolTargetSource definition shown above as follows. (the name of the definition has also been changed, for clarity.)

<object id="prototypeTargetSource" 
        type="Spring.Aop.Target.PrototypeTargetSource, Spring.Aop">
    <property name="targetObjectName" value="businessObject" />
</object>

There is only one property: the name of the target object. Inheritance is used in the TargetSource implementations to ensure consistent naming. As with the pooling target source, the target object must be a prototype object definition, the singleton property of the target should be set to false.

ThreadLocal target sources are useful if you need an object to be created for each incoming request (per thread that is). The concept of a ThreadLocal provides a facility to transparently store resource alongside a thread. Setting up a ThreadLocalTargetSource is pretty much the same as was explained for the other types of target source:

<object id="threadlocalTargetSource" 
        type="Spring.Aop.Target.ThreadLocalTargetSource, Spring.Aop">
    <property name="targetObjectName" value="businessObject" />
</object>