views:

334

answers:

2

A few months back I've discovered PostSharp, and for a time, it was good.

But then legal came back with an answer saying that they don't like the licence of the old versions. Then the department told me that 2.0's price was unacceptably high (for the number of seats we need)... I was extremely disapponted, but not disheartened. Can't be the only such framework, I thought.

I kept looking for a replacement, but most of it was either dead, ill maintained (especially in documentation department), for academic use, or all of the above (I'm looking at you Aspect.Net)

Then I've discovered Spring.Net, and for a time, it was good.

I've been reading the documentation and it went on to paint what seemed to be a supperior picture of an AOP nirvana. No longer was I locked to attributes to mark where I wanted code interception to take place, but it could be configured in XML and changes to it didn't require re-compile. Great.

Then I looked at the samples and saw the following, in every single usage scenario:

// Create AOP proxy using Spring.NET IoC container.
IApplicationContext ctx = ContextRegistry.GetContext();
ICommand command = (ICommand)ctx["myServiceCommand"];    
command.Execute();
if (command.IsUndoCapable)
{
    command.UnExecute();
}

Why must the first two lines of code exist? It ruins everything. This means I cannot simply provide a user with a set of aspects and attributes or XML configs that they can use by sticking appropriate attributes on the appropriate methods/classes/etc or editing the match pattern in XML. They have to modify their program logic to make this work!

Is there a way to make Spring.Net behave as PostSharp in this case? (i.e. user only needs to add attributes/XML config, not edit content of any methods.

Alternatively, is there a worthy and functioning alternative to PostSharp? I've seen a few question titled like this on SO, but none of them were actually looking to replace PostSharp, they only wanted to supplement its functionality. I need full replacement.

+2  A: 

In short, yes, Spring.Net AOP can work in the way you describe using XML-based configuration: you do not have to use those initial two lines of code, in fact code-based configuration is discouraged. You can configure Spring.Net AOP using XML-based configuration only and this is in fact the recommended approach.

There are several steps to this:

  1. Create your advices: BeforeAdvice, AroundAdvice, AfterReturningAdvice and ThrowsAdvice are the types of advice supported. AroundAdvice uses the AOPAlliance interface, the others use the Spring.AOP interfaces.
  2. Define your pointcuts
  3. Apply the pointcuts and advice

Example configuration (generalized from a live configuration):

  <!-- START Spring.Net AOP -->

  <object id="beforeAdvice" type="MyBeforeAdvice, MyAOP"></object>
  <object id="beforeAdvisor" type="Spring.Aop.Support.DefaultPointcutAdvisor, Spring.Aop">
    <property name="Advice" ref="beforeAdvice" />
  </object>

  <object id="returnsAdvice" type="MyAfterReturningAdvice, MyAOP"></object>
  <object id="returnsAdvisor" type="Spring.Aop.Support.DefaultPointcutAdvisor, Spring.Aop">
     <property name="Advice" ref="returnsAdvice" />
  </object>

  <object id="throwsAdvice" type="MyThrowsAdvice, MyAOP"></object>
  <object id="throwsAdvisor" type="Spring.Aop.Support.DefaultPointcutAdvisor, Spring.Aop">
    <property name="Advice" ref="throwsAdvice" />
  </object>


  <!-- Advise objects -->
  <object type="Spring.Aop.Framework.AutoProxy.ObjectNameAutoProxyCreator, Spring.Aop">
    <property name="ObjectNames">
      <list>
        <value>*Command</value>
        <value>...</value>
      </list>
    </property>
    <property name="InterceptorNames">
      <list>
        <value>beforeAdvisor</value>
        <value>returnsAdvisor</value>
        <value>throwsAdvisor</value>
      </list>
    </property>
  </object> 


  <!-- END Spring.Net AOP -->

Weaving is performed at runtime and is pretty fast and unintrusive.

Hope this is of use,

Andrew

Alfamale