SheepAspect: Mixin

SheepAspect Preview-3 was released today, and one of the most important new features is Mixins. In Preview-2, there were only one advice implementation: [Around]. In preview-3 we introduce two more advices: [DeclareMixin] and [DeclareAttributes].

[DeclareMixin] advice allows you to add new interface implementations on existing classes. As an example, here is a plain simple Customer class:

public class Customer
{
	public string FirstName {get; set;}
	public string LastName {get; set;}
}

And a completely unrelated IEmailable interface:

public IEmailable
{
	public string EmailAddress {get; set;}
	public void SendEmail(string subject, string body);
}

Now let’s stitch these two together using SheepAspect mixin

[SingletonAspect]
public class SmtpAspect
{
	[SelectTypes(typeof(Customer))]
	public void Customer(){}

	[DeclareMixin("Customer")]
	public IEmailable CreateCustomerEmailable(Customer customer)
	{
		return new CustomerSmtpEmailable(customer);
	}

	private class CustomerSmtpEmailable: IEmailable
	{
		private readonly Customer _customer;

		public CustomerSmtpEmailable(Customer customer)
		{
			_customer = customer;
		}

		public string EmailAddress { get; set; }

		public void SendEmail(string subject, string message)
		{
			/* Just pretend this code is going to an SMTP server, not to a console */
			Console.WriteLine("To: {0} {1} ({2})", _customer.FirstName, _customer.LastName, EmailAddress);
			Console.WriteLine("Subject: {0}", subject);
			Console.WriteLine("\nMessage:");
			Console.WriteLine("Hola {0},", _customer.FirstName);
			Console.WriteLine(message);
			Console.WriteLine("\nSincerely yours");
			Console.WriteLine("Sheep");
		}
	}
}

With this aspect in place, your Customer class now magically implements IEmailable interface. The invocation will be directed to the implementation we have provided in our aspect (CustomerSmtpEmailable), which contains the infrastructure code of sending an email through an SMTP server or background tasks. Now you can actually cast your Customer arbitrarily to an IEmailable:

var customer = new Customer {FirstName = "Henders", LastName = "Sheep"};

var emailable = (IEmailable) customer; // Casting a Customer into IEmailable!

emailable.EmailAddress = "henders.sheep@foo.com";
emailable.SendEmail("Buy now!",
    "We have a great collection of sheep for you to buy.\nHurry, while stock lasts!");

That actually works, and you did not get InvalidCastException. Instead you’ll get this little output on your console window:

image

All source-code in this example can be found in SheepAspect.Example project on SheepAspect code repository.

Binding Mixins to Fields

Instead of declaring Mixin implementation factory method, you can also bind your Mixin implementations on aspect fields. For instance:

[SingletonAspect]
public class SmtpAspect
{
	[DeclareMixin("CustomerTypePointcut")]
	public IEmailable _customerEmailable;
}

Now your Customer will implement IEmailable interface that directs its execution to the IEmailable instance held by this _customerEmailable field on your SmtpAspect. Swapping the implementation of your Customer’s IEmailable is as simple as setting the value of this field.

Dependency Injection: Reborn

Some time in our career, we have learnt about separation of concerns, about how you should split domain-code from infrastructural concerns. Usually this is achieved by means of dependency-injection, the goal of which is to promote loose-coupling, maintainability, and testability. Dependency-injection has become one of the most fundamental principle in OO application development. But this is a principle that might no longer be relevant in AOP world.

The premise of dependency-injection does not necessarily hold true in AOP development process. There is no longer much need of rearchitecting your classes to fit into dependency-injection scheme just to achieve separation of concerns. You can in fact just implement your infrastructural concerns directly as part of your Customer domain class. For typical CRUD applications, you can do away without repository classes: you just simply inject ActiveRecord capability straight onto your entities through mixin.

Feeling dirty? Not quite. Separation is still maintained because these implementations are actualised as separate mixins that are injected externally by aspects where you consolidate all your infrastructural plumbing.

In our Customer/IEmailable example, neither your Customer class, IEmailable interface, nor their consumers are aware of any SMTP implementation. They are pure POCO. Then somewhere completely external to the core of your application code, you just introduce SmtpAspect mixins aspect where you actually implement your SMTP plumbing, and will statically enhance your customer class with SMTP capability. But from code perspective, your Customer class remains a simple POCO model.

For unit-testing, you can mock SmtpAspect class, and reimplement the IEmailable behavior with mocked behaviors.

Yes you do violate dependency-injection principle, you sinfully commit God-Object anti-pattern, but hey, those wisdoms was invented before the birth of AOP into static languages.

SheepAspect Preview 3

This is not a massive release or anything. The idea is to push new changes rapidly to the public to attract early feedbacks, especially because this Preview3 release comes with a good set of new features and improvements that I genuinely feel very excited about. Many of these changes are based on feedbacks I have received from early adopters. So thanks to everyone who has shared their inputs.

What’s New

There is no significant changes on the underlying SheepAspect framework itself. This release is more of implementing new functionalities and natural progression of the feature-set of the library. Some of these new features are:

  1. The most significant new feature in Preview3 release is the Mixins support. With the new [DeclareMixin] advice, you can now statically add interface implementations to existing classes. I will write have written the details of this in a separate post.
  2. We also now have [DeclareAttributes] advice attribute. With this advice, you can statically add attributes to existing types, methods, properties, fields, and constructors. This will also be covered in the upcoming posts.
  3. IAspectAware interface, so you can now intercept when your aspects get instantiated by AspectRuntime so you can execute some initialisation routine. Again, this will be covered in the upcoming posts.
  4. A more complete set of pointcut implementations. Preview-2 advices could only target methods, properties, and instructions (method-calls, field gets/sets). In preview-3, they can also target types, constructors, fields, and property getters/setters. Events are only partially supported at the moment.
  5. Intellisense documentation. I understand that SheepAspect has a very steep learning curve. It can be overwhelming for users to get started or to figure out what each attribute does. In this Preview 3 release, most of SheepAspect’s public API is well documented.
    image10image9
  6. In Preview 2, SheepAspect required pdb files of all target binaries (so that SheepAspect can preserve debuggability of your weaved binaries). This has caused a problem for users who do not have pdb files of their target binaries. In Preview 3, pdb files are optional.

Get It Now

As usual, SheepAspect Preview3 is installable from NuGet: https://nuget.org/packages/SheepAspect. SheepAspect-Query-Analyzer for Preview-3 version is still due to come soon, and will be downloadable separately on the SheepAspect homepage.

UPDATE: SheepAspect-Query-Analyzer is now always included when you install via NuGet, under the Tools directory within the SheepAspect package folder.

SheepAspect Preview 2!

I’m very excited to announce the second preview release of SheepAspect. It’s available now, and you can install it to your project from NuGet gallery.

There are few new features introduced on this release, such as changes around its API, introducing more simplicity, bug fixes, and improved implementations. But there are few things that I’d like to highlight what’s new in this release.

NuGet Package

Previously, installing SheepAspect has always been a bit of a mess. You had to reference few libraries into your project, copy some compiler.exe into a folder, modify your csproj manually to include the compiler into your build-task, and pray all the stars are lined up in a perfect angle.

Now in Preview-2, NuGet will do all the mundane heavy-lifting for you. The only step you need to do now is to NuGet SheepAspect straight to your main project, and that’s it. Everything will be configured for you, and you’ll be all set to go before you finish reading this sentence.

When you NuGet SheepAspect into your project, there are 4 things that happen:

  1. It downloads all binaries and compiler into your project, and attach the necessary runtime libraries into your project references.
  2. It modifies your .csproj/.vbproj file to hook SheepAspect compiler into your post-build task.
  3. Generates a default configuration file (SheepAspect.config) and add to your project. This file has been pre-configured to just work immediately, which you can then use as a starting point to configure your SheepAspect settings. (More about this below).
  4. You’ll also be given one sample aspect class (/Aspects/SampleAspect.cs), and all it does is trace-logging around all public methods within your current project. (Entry, exit, exceptions).

The included sample-aspect is readily active and all fully functioning out-of-the-box, so that as soon as you nuget SheepAspect into your project and hit run immediately, you’ll watch all your public methods are now writing log traces to your debug window. From here, you can use this sample ‘SampleAspect.cs’ as a template to get started to write your very own first aspects.

SheepAspect.config

Another new feature introduced in Preview-2 is an easier configurability. So instead of tinkering with your .csproj/.vbproj msbuild tasks to configure SheepAspect compilation settings, you can now do so in SheepAspect.config. When you install SheepAspect, you’ll get a default config:

<?xml version="1.0" encoding="utf-8" ?>
<sheepaspect-config xmlns="urn:sheepaspect-config-1.0">
  <aspects>
    <assemblies>
      <include>YourProject.exe</include>
    </assemblies>
  </aspects>
  <weave>
    <assemblies>
      <include>YourProject.exe</include>
    </assemblies>
  </weave>
</sheepaspect-config>

It’s pretty straightforward. The xsd file is included so you can use Visual Studio intellisense to view all the different settings, although it’s all pretty basic at this point.

Build Report

SheepAspect compiler task spawns a separate (console) process to get around Visual Studio annoying tendency to lock dll files that you access during the task. That’s why in Preview-1 you could briefly see a console window popping up during compilation process. When an error occurs during the compilation, you’ll need to read the report printed on the console window.

The new SheepAspect is still using the same technique, but it’s more refined and well hidden. You won’t see any window popping up, and your compilation results will be reported nicely on your Visual Studio.

SheepAspect Query Analyzer

I have announced SAQA before, but this is the first time it has ever been released. SAQA’s releases will roughly follows the release cycle of SheepAspect, but it’s distributed as a separate download. You can download SAQA for SheepAspect Prevew-2 here on the project website.

Factory Per Aspect

Aspect factory determines how your aspect classes are instantiated during runtime. In the previous version, aspect factory was defined globally.

AspectFactory.Current = new StructureMapAspectFactory(structureMapContainer);

But there are times when you need to use a specific factory for your particular aspect. For example to instantiate your aspect from attribute declaration, or to instantiate from web-request (model-binding) or client cookie. New in Preview-2, now you can define your factory on a per-aspect basis.

[Aspect]
[AspectFactory(typeof(AttributiveAspectFactory))]
public class MyAspect
{
}

If no particular factory specified for your aspect, SheepAspect will resort to a global default factory.

AspectRuntime.Provider.DefaultFactory = new StructureMapAspectFactory(structureMapContainer);

That’s right, you’ve just seen AspectRuntime there. It’s a new addition in SheepAspect Preview-2 that gives you access to the runtime environment of your aspects. You can, for example, switch off all your aspects (or a specific aspect) for unit-testing purpose, or even to replace your aspect with a mock. You can inquire the lifecycle of your specific aspect, or even change them (e.g. from Singleton to PerThis). You can ask for the instance of a specific aspect for a particular jointpoint, and so on. It gives you a flexible and dynamic control upon your aspect-orientated runtime behaviors that can’t be scripted during compile-time alone.

SheepAspect

This is also the first release since the project changed its name from SheepAop. So if you’re using Preview-1, the upgrade path to Preview-2 will be a breaking and rocky one. But I’m very excited about this release, I’d strongly urge to to upgrade if you’re already on Preview-1, or to start trying out and play around with SheepAspect if you haven’t. So go on, it’s only a NuGet away 😉

These preview releases have always been about giving people an early access to gather as much feedback as I can. So any comments/issues/suggestions, as always, would be greatly appreciated 🙂

[More about SheepAspect]

SAQL and SheepAOP Remake

SAQL?

Say hello to SheepAOP-Query-Language (hereafter referred to as ‘SAQL’), a new addition to SheepAOP, serving as the main language to query against your source-code for your SheepAOP pointcut definitions.

I know I said external-DSL would NOT be in my priority list, but the latest SheepAOP enhancement I was working on (outlined later) has made it strongly imperative that an external DSL needed to be brought onto the game, right now.

Initially, I took the path which follows the current trend in .Net libraries designs that have been increasingly moving away from external DSL in favor of lambda Fluent APIs. To name a few: NHibernate’s HQL taken over by NH2Linq, HBM by Fluent-NHibernate, Binsor by fluent-configuration, and I myself have also built lambda API in lieu of RhinoETL’s boo scripts. Lambda seems to be the new black. Therefore, at the beginning of SheepAOP project, it was very clear to me that Fluent lambda was the way to go about this whole AOP thing. With lambda API, I would get the intellisense and refactoring support from Visual-Studio, and I actively avoided the tedious effort of building an external DSL from scratch.

Over the weeks, I have been noticing few minor issues with lambda API that have been irritating me, albeit not to a point that bothers me enough to do anything about it.

  1. Safety. SheepAOP weaving is done during compile-time whenever you build your project. I have not been particularly happy about the fact that SheepAOP compiler needed to execute your actual application (i.e. your configuration routines) during compilation, as opposed to reading only its metadata. If you’re not careful, you might accidentally (or deliberately) execute certain unintended code-blocks (from within your config routine) during compile time, which might be harmful to anyone merely opening the project in their Visual-Studios. It makes it way too easy to abuse.
  2. File lock. Since your application are executed (by SheepAOP) during VisualStudio compilation, they would get loaded into your VS process, and will never get release (There’s no such thing in the .Net framework as “unloading” an assembly). It also means it will lock your output file, something you don’t want on an IDE. Spawning separate AppDomain normally solves this, but that doesn’t do the trick on VS custom-tasks for whatever reason. My current solution is to spawn a separate (console) process. Either way, lambda configuration makes communications difficult since they are not transmittable between AppDomains/processes. A plain DSL text-script, on the other hand, is.  Hence giving me a lot more flexibility in my approaches.
  3. Verboseness. Lambda API introduces too much noise for the signal. We will see this in comparison shortly.

Those are 3 minor drawbacks that I could happily live with, rather than spending my effort on an external DSL that could be spent elsewhere. Plus I was reluctant to give up IDE intellisense with fluent API.
But as I worked on the next enhancements (covered below), it quickly became obvious that fluent API no longer finds its place in the system, and I came to a tough decision to ditch the whole thing, and started working on a brand new querying language.

SheepAOP Enhancements

After exploring several common patterns and use-cases frequently seen on other more mature AOP tools like AspectJ, and then reviewed the current (previous) implementation of SheepAOP, I determined that the old SheepAOP design wasn’t up for the job. A total rework had to be done. The 3 major features that inspired the rework, which have now been delivered on the new version of SheepAOP, are:

  1. Aspect Lifecycle. This is a very important feature that single-handedly makes AOP useful in far broader sets of real-world problems. So far I have only seen this in AspectJ. I will post more elaborately on this one particular topic, but in essence, it allows you to determine the lifespan of your aspects, so you can maintain contextual states.
    For example, imagine you just defined a new client-facing method (say: MethodA) for your POS system, exposing a transactionTime as a parameter that the client (human or another app) can specify, so that all sales-order objects constructed at any point within the scope of that method will be initialized with this transaction-date. Normally this means that you will have to pass this date from MethodA all the way through all methods beneath its flow, to be used in every sales-order instantiation it reaches.
    With PerFlow lifecycle (new!), you can define that your aspect’s life will start when the MethodA starts. It will then begin intercepting all sales-order instantiations within the flow, and assign them with the transaction-date (captured from before). When MethodA completes, this aspect will also be disposed out of the way, which also ends its intercepting business. With a pseudo-code, your aspect looks like:

    [Lifecycle (PerFlow of "MethodA_called")]
    aspect TransactionDateAspect:
    {
       // Normal instance field, stays here within the life of this aspect object
       private Date _transactionDate;
    
       pointcut MethodA_called;  // The "life trigger" for this aspect, as declared on the top
       pointcut SalesOrder_instantiation;
    
       [Before(MethodA_called)]
       void OnMethodA_called(Date transactionDate)
       {
           // Aspect initiates here. Let's keep the transaction-date within the context
           this._transactionDate = transactionDate;
       }
    
       [After(SalesOrder_instantiation)]
       void  SalesOrder_instantiation (SalesOrder order)
       {
          // This advice is only active within the life of this aspect
          order.TransactionDate = this._transactionDate;
       }
    }
    

    This ability enables you to compose an aspect-oriented workflow. There are many other lifecycles, for example: PerTarget aspects allow you to cache method-calls to the same object instance. PerThis allows you to keep all dirty states within that instance. Singleton and Transient are the other options.
    The reason this could not be done on the previous SheepAOP design was because all advice-methods had to be static since they merely acted as code templates to be copied to the injected targets (which also causes the problem in point#3).

  2. Inheritance, Polymorphism, and Abstract Aspects. Now that we have aspects and pointcuts as normal living instances (as opposed to a bunch of static instruction templates), you can use inheritance and polymorphism around your aspects for reusability and extensibility. For instance, you can define the following abstract aspects (this one is an actual SheepAOP code):
    public abstract class LoggingAspectBase
    {
       protected abstract string Title();
    
       protected abstract void LoggablePointcut(); // Override your pointcut here!
    
       [Around("LoggablePointcut")]
       public object LogExecution(JoinPoint jp)
       {
          try
          {
             _logger.Log("Entering {0} with [{1}]" + Title(), jp.Args);
             var result = jp.Proceed();
             _logger.Log("Returning {1} from {0} " + Title(), result);
             return result;
          }
          catch(Exception e)
          {
             _logger.Log("Error on {0}: {1}", Title(), e);
          }
       }
    }
    

    And you can reuse this base-aspect class by simply implementing it.

    public class OrderSubmissionLogging: LoggingAspectBase
    {
       protected override string Title()
       { return "Order Submission"; }
    
       // Overriding your pointcut
       [SelectMethods("Name:'SubmitOrder' & InType:(Namespace:'Sheep.Sales.*')")]
       protected override void LoggablePointcut(){}
    }
    
  3. No method-copier, means better debugger. As explained in the previous posts, the old SheepAOP used your advice-methods as a code-template, in a literal sense, copying the body line by line to surround the target code-blocks. (Think T4). Because your advice-methods were only templates and never got executed, it naturally means your debugger would never arrive there. I suggested event-based advices to “solve” that, which I have to admit, a bit clunky, unpredictable, and error-prone.
    The new SheepAOP will no longer employ this “code-template” technique. It now makes use of .net delegates. SheepAOP now pulls your code-blocks into statically-generated methods, and keeps the delegates of them, so your application will literally jumps back and forth between these delegates. Your debugger will be able to cope with that. It also means that you can even make your advice call your target methods several times. E.g.:

    public int Advice(JoinPoint jp)
    {
       var returnValue= jp.Proceed();
       returnValue+= jp.Proceed();
       returnValue+= jp.Proceed();
       return returnValue;
    }
    

    That advice would execute your target methods 3 times, and yup, this time is for real: your advice method actually gets executed during runtime. When you call jp.Proceed(), beneath the skin it will simply make a delegate call that points back to your hidden underlying target code-block.

These changes demanded a major change. I had to rewrite the project pretty much from scratch. How does this affect Fluent API? Let’s see.

The shift from static advices and pointcuts into active instances (especially to support inheritance at point#2) means that SheepAOP will now have to instantiate your actual aspect classes in order to execute its configuration routines (and their inheritances). The same aspect classes that are also used during the runtime.
I don’t like this. Your classes typically have certain instantiations routine required during the runtime (e.g. application-settings, dependency-injects, even sometimes database-connections). The fact that now I have to execute the same runtime routines as part of my compilation process really bothers me. And once you get the actual runtime instance of your object, it really becomes inevitable to make “accidental” abuse within your AOP configuration code. It was aggravated by the ever swelling number of generics tags and lambda arrows noise thanks to the fast growing need for a more expressive configuration system, I eventually determined that this is a good time for the birth of SAQL.

SAQL!

Ok, this will be brief. I’ll just give a comparison of the same pointcut between the old syntax and the new one. I will deliberately use a dreadfully complex example to magnify the difference.

Old Fluent API:

[RegisterPointcut]
public static void MyPointcut(PointcutRegistry reg)
{
   reg.Advise(r=> r.Method(m=>
      m=> m.Name("Save").And(m1=>
            m1.IsStatic(true)
            .DeclaringType(t=> t.Namespace("Sheep.Data.*"))
            .Arg(t=> t.Any())
            .Arg(t=> t.AssignableFrom(i=> i.FullName("NHibernate.ISession")))
         .Or (m2=>
            m2.IsStatic(false)
            .DeclaringType(t=> t.Implements(i=> i.FullName("Sheep.IRepository`1")))
           ))
      ), MyAdvice);
}

SAQL:

[SelectMethods(
    @"Name:'Save' &(
       IsStatic & InType:Namespace:'Sheep.Data.*' & Args:( , (AssignableFrom:'NHibernate.ISession'))
       || !IsStatic & InType:Implements:'Sheep.IRepository`1'
      )"
)]
public void MyPointcut() {}

The 2 codes above are querying exactly for the same pointcuts, resulting in exactly the same joinpoints. But I believe the second one using SAQL is much easier on eyes. The noise is kept minimum in the syntax. That SAQL query will then be lexed, parsed, and walked using ANTLR3 into a workable AST, that’s in turn translated into SheepAop Pointcut objects, ready to crunch your assemblies (fed by mono-cecil) to find the matching code-blocks within your assemblies.

As for the grammar, I actively avoided using words as part of the syntax (like in SQL and HQL) , because even though it makes it easier to read, it makes it harder to write. You might sometimes find yourself wondering whether you have to use ‘where‘, or ‘is‘, or ‘not in‘, or ‘is not in‘ in specific instances. I believe a consistent use of small number of punctuations makes for a more intuitive experience. But I’m open to feedback regarding the language grammar.

Where’s The Stuff?

No surprise here, everything is in the Codeplex repository (http://sheepaop.codeplex.com/). I haven’t produced a release for this yet since this is still very unstable, especially in the error-detection department (EDIT: and Generics situations, which is unexpextedly very tricky).

I will post next articles to explore the various features I’ve only briefly alluded above:

  • SAQL basics
  • Abstract aspects and polymorphism
  • Aspects lifecycle (real world examples of “contextual aspects”)
  • Aspect factory (connecting your beloved IoC to SheepAOP)
  • Debugging tips

Announcing SheepAOP (Part 2)

This post is the excerpt from yesterday’s presentation about the new SheepAOP project that I’ve just started recently.
All code exercises in this post can be found under SheepAop.Samples project as part of the SheepAop repository (http://sheepaop.codeplex.com/)

Part 1 – AOP for Everyone
Part 2 – SheepAOP Basics

Some Arbitrary Application

We need to start somewhere, so why not from this simple meaningless code?

class Program
{
    static void Main()
    {
        IoCConfig.Bootstrap();

        var result = "Elephant".CalculateAdsFee(10);
        Console.WriteLine("Index: {0}", result);

        Console.ReadLine();
    }
}

public static class StringHelper
{
    public static int CalculateAdsFee(this string text, int rate)
    {
        Console.WriteLine("Calculating {0}... ", text);
        if(text.Length < 15)
            return text.Length*rate;

        Console.WriteLine("Maximum fee!!");
        return text.Length*rate + 15;
    }
}

image

No surprise there. 8 characters in “Elephant”, charged at $10 rate, calculates into $80.

Your First Aspect

Now let’s create a pointcut to target StringHelper.CalculateAdsFee(string, int) method above. In this case, I’ll say all methods beginning with word “Calculate”, declared within any type ending with word “Helper”:

public static class DemoAspect
{
    [RegisterPointcut]
    public static void CalculateFeePointcut(PointcutRegistry reg)
    {
        reg.AddCurrentAssembly().Advise(m => m.Method
            .Name("Calculate*")
            .DeclaringType(t => t.Name("*Helper"))
            , DemoAdvice);
    }
}

We have our pointcut, and as you see, we advise it with “DemoAdvice”, which doesn’t exist yet. So let’s create one now (visual-studio or resharper will help you with this).

private static void DemoAdvice(MethodJointPoint jointpoint)
{
    Console.WriteLine("Demo advice for {0} from {1}", jointpoint.Args[0], jointpoint.Method);
    jointpoint.ReturnValue = 10000;
    Console.WriteLine("Leaving demo advice");
}

This method will never get executed. It will only be interpreted at the compile time to decorate your original StringHelper methods.

What we’ve just done there in this case, is that we have swapped completely the body of our original StringHelper method with these 3 lines of code we have just introduced in our advice. This is a crude way of creating an advice, we’ll see later a gentler way of doing this. But for now, let’s see the result:

image

Let’s see with the debugger, and keep hitting F11.

image
image
image

The execution jumps straight out from the CalculateAdsFee method, and returns 10000 immediately. This is because the whole method body of CalculateAdsFee() is no longer there, as we instructed SheepAOP to replace it with the new content, which simply returns 10000.

That’s rarely what we want. So let’s now change our DemoAdvice to the following:

private static void DemoAdvice(MethodJointPoint jointpoint)
{
    Console.WriteLine("Demo advice for {0} from {1}", jointpoint.Args[0], jointpoint.Method);
    jointpoint.Args[0] = "Sheep!!";

    JointPoint.Proceed(); // LOOK HERE!

    jointpoint.ReturnValue = (int) jointpoint.ReturnValue + 100;
    Console.WriteLine("Leaving demo advice");
}

JointPoint.Proceed() on line#6 only contains “throw NotSupportedException” if you execute it. But that’s fine because advice methods never actually get executed. Only intepreted as a template during compile time.
JointPoint.Proceed() is a keyword that will be used by SheepAop compiler as a marker that that’s where the original method body should go. So if we run the application again, we’ll get:

image
image

image

image

image

image

Between step#2 and step#3, you can see that the parameter text changes its value magically from “Elephant” to “Sheep!!”. On step #4, the method was returning 70*10=70, but the actual return value immediately changed to 170 on step#5. These behaviour changes are caused by the advice what we specified earlier: we change args[0]=”Sheep!!”, and we also increment the ReturnValue by 100 (hence resulting in 170).

You have seen the basic of what you can do with Advice. You can do pretty much what you can with a normal code. You can check if a value is within a certain range, and alter the flow of the execution.

Altering Specific Lines Of Code

This example will seem a bit crazy, that’s because I am using an incredibly unrealistic example, just to demonstrate the kind of thing you can do with SheepAOP. Here’s the initial code:

class CrazyProgram
{
    static void Main()
    {
        IoCConfig.Bootstrap();

        string str = null;
        Console.WriteLine("Index of z: {0}", str.IndexOf('z'));

        Console.ReadLine();
    }
}

That line#8 is surely going to crash spectacularly, and rightly so.

imageimage

Even if we put an aspect inside of the string.IndexOf(char) method, that won’t help since the method won’t even get called in the first place.

So instead, let’s now write a SheepAOP aspect to target that specific line of code.

public class CrazyAspect: IAspect
{
    [RegisterPointcut]
    public static void CrazyPointcut(PointcutRegistry reg)
    {
        reg.AddCurrentAssembly().Advise(r=> r.Instruction
            .MethodCall(
                m=> m.Name("IndexOf").DeclaringType(t=> t.Is()))
            .ExecutedIn(
                m=> m.DeclaringType(t=> t.Is())
            ), CrazyAdvise);
    }

    private static void CrazyAdvise(MethodCallJointPoint jointpoint)
    {
        jointpoint.TargetInstance = "crazy";
        JointPoint.Proceed();
    }
}

So there, we create a pointcut to target a specific instruction line in the code. There are several types of instruction we can target, for example, setting a field, getting a field, “new” instantiation, equality comparison, etc, but in this case, we want to target the “method call to string.IndexOf(char)” from any line of code “executed within any method in the CrazyProgram class”.

PS: The ExecutedIn() criteria can be handy to define different advices for a particular instruction executed from different contexts. For example, we can define that when we call “new Customer()” from within the VIP area, then we will return a new instance of VIPCustomer instead.

Now if we execute the application again, we’ll get:

imageimageimage

This time, the line passed through successfully, even though the str value is still null. What happens here is that we have just redirected the call to string.IndexOf(‘z’) method to an instance of string value “crazy”, rather than its original null instance, and hence returning 3 (the index of ‘z’ in ‘crazy’).

That was a silly example, but it shows you how you can use SheepAop to reach virtually any part of your code. Not only methods and properties.

Event Driven Aspects

I do NOT recommend you writing advices using the approaches I have been using in all previous examples. There are 2 disadvantages of it:

  • Your advice will get welded straight to the target assembly, meaning that you won’t be able to change your advices dynamically at runtime
  • Since your advice methods are copied across during compilation, and never actually gets called, you won’t be able to follow it with debugger. There’s too much invisible surprises involved, which is why I strongly discourage this approach. For instance, if you look back to your first Aspect that we wrote, our debugger shows some invisible magic at the beginning of your method that changes your “Elephant” into  a “Sheep”.
    image
    image

There is an extension method on the PointcutRegistry to alleviate this problem. It’s called: Listener. Now let’s change our DemoAspect from our first example to the following:

public class DemoAspect: IAspect
{
    [RegisterPointcut]
    public static void CalculateFeePointcut(PointcutRegistry reg)
    {
        reg.AddCurrentAssembly().Listen(m => m.Method
            .Name("Calculate*")
            .DeclaringType(t => t.Name("*Helper")));
    }

    public void Init()
    {
        var listener = Listener.Method(CalculateFeePointcut);
        listener.OnEntry += (j, c) =>
        {
            Console.WriteLine("Demo advice for {0} from {1}", j.Args[0], j.Method);
            j.Args[0] = "Sheep!!";
        };
        listener.OnExit += (j, c) =>
        {
            j.ReturnValue = (int)j.ReturnValue + 100;
            Console.WriteLine("Leaving demo advice");
        };
    }
}

You’re not actually losing any functionality. You can do almost anything you could do with the old way. There are 3 events you can subscribe to: OnEntry, OnExit, and OnException.
Now if you run the debugger again, you will get the following:

image
image

image

On step#2, the debugger steps through your event handler, where you can inspect all the runtime details about the jointpoints. Now you can see everything that is going on. There’s no more code that’s not visible from the debugger.

And since your advice is now event-driven, you can subscribe and modify your advice at runtime however you like.

You can, for example, use plugin architecture to attach to these events to affect the intimate behaviour of your application dynamically. This is normally done using MEF or IoC using some sort of service-location pattern that you put in place in your application as a set of predefined extension points. AOP offers a less intrusive way of doing it, where you are not forced to reshape your architecture in any specific way to allow an injection of dynamic behaviours to your application via plugins and events. CQRS is another exciting possibility (where your reporting-context would unobstrusively subscribe to specific “pointcuts” within your domain-models).

Sometimes you still need to use the plain Advice, usually if your advice is surrounding your pointcut, for example: stopwatch to time around your pointcut, transaction-scope, or disposable objects. But when you do need to use Advice, try to extract out all logic into a separate public method. Remember that only the content of your Advice method gets copied across. So if you put your logic in a separate method, you will be able to use debugger on it. So only use the Advice method to declare control-flow, and leave any logic out. Try to keep your advice as lean as possible, and you’ll get as little surprise as you can afford.

Shopping Cart

Finally, to refresh our memory, here’s the aspect example from our previous post about the shopping-cart.

public class PurchasingNotificationAspect: IAspect
{
    [RegisterPointcut]
    public static void SetProductPointcut(PointcutRegistry reg)
    {
        reg.AddCurrentAssembly()
            .Listen(r => r.Setter(p => p.StockQty));
    }

    private readonly INotificationService _notifier;

    public PurchasingNotificationAspect(INotificationService notifier)
    {
        _notifier = notifier;
    }

    public void Init()
    {
        Listener.PropertySet(SetProductPointcut).OnExit += (j, c) =>
        {
            if ((int)j.Value < 5)
                _notifier.Send(Notice.Restock, (Product) j.Instance);
        };
    }
}

Setup

To You need to attach SheepAop compiler to your project (containing your aspect definitions) to weave your assemblies (any assembly, doesn’t have to be the project assembly itself). For example, our SheepAop.Samples project has the following lines defined in its csproj file. You will need to do the same for any project using SheepAOP aspects.

<PropertyGroup>
   <SheepAopLocation>$(MSBuildProjectDirectory)\Libs</SheepAopLocation>
</PropertyGroup>
<UsingTask TaskName="PostCompileWeaveTask" AssemblyFile="$(SheepAopLocation)\SheepAop.Tasks.dll" />
<Target Name="AfterBuild">
   <PostCompileWeaveTask TargetFile="$(MSBuildProjectDirectory)\$(OutputPath)$(MSBuildProjectName).exe" Namespace="SheepAop.Samples.*" SheepAopLocation="$(SheepAopLocation)" />
</Target>

Where to Next?

In very near future, these are the things that will keep me busy:

  1. Mixin support
  2. Support for Attribute style aspects
  3. Add more aspect supports for many other IL constructs (e.g. c# “new” keyword, constructors, ==, etc).
  4. Groking AspectJ

What I’m not gonna do (but would love if anyone could help):

  1. External DSL (ala AspectJ)
  2. IDE integration (background analysis and indexing to speed up compilation time)

Feedback?

This project started as my learning attempt. I’m happy with all the learning gained in the past few days around IL, Mono.Cecil, and AOP in general. I’m still learning and experimenting with this project, and I am looking forward to hear any feedback and advice. I’ve put all the source-code out there, so feel free to explore, scrutinize, and I’d be pleased to hear any area that can be improved, both in the coding department (maintainability) as well as performance.

And of course, any contribution will be more than welcomed.

Download

You can download the full source-code of SheepAOP and all examples in this post (and the previous post) in the SheepAop main repository in Codeplex (http://sheepaop.codeplex.com/).

Announcing SheepAOP (Part 1)

Not the wittiest name, I realize, but certainly among the top in the cuteness league. SheepAOP is yet another AOP tool for the .NET environment (which frankly aren’t that many). It uses IL weaving to inject croscutting concerns to your dll at compile time. (And soon, SheepAOP will also support IL weaving at assembly load-time as an alternative, leaving the original dll intact).

The project is still in its very early inception, it just started last week, so I’m all ears to as many feedbacks as I can get.
I did a presentation on this yesterday, which I’m going to recap here in this 2-part-series.

Part 1 – AOP for Everyone
Part 2 – SheepAOP Basics

AOP for Everyone

SheepAOP project is driven primarily by experimental intents, but its ultimate goal is to make AOP more accessible for .NET developers.
In today’s climate, when we talk about AOP, we normally would only use it for things of the grandest scale, like transaction-management, logging, security authentication, and all that sort. But there are many trivial things in our everyday work that we won’t immediately think of AOP. In those instances, we usually feel like we need an intensely compelling reason before we even think about resorting to AOP. I think this is down to the lack of the tooling, especially in the .Net space, where AOP has become something highly exotic.

This is what I intend to change, by bringing in a free alternative onto the table, making AOP a bit more accessible that hopefully people would just go ahead and start writing aspects for simple things without thinking much about it, just like what people do in Java for instance, where AspectJ has become a defacto standard, so ubiquitous that whenever you sense the slightest need for an aspect, chances are you already have AspectJ within your library stack, so you just go ahead and write your aspects.

Simple Everyday Thing

Nothing is simpler than the cliché Shopping Cart example, a bare one notch above Hello World. So let’s use this as our example.

public class ShoppingCart
{
    public void AddProduct(Product product, int qty)
    {
        product.StockQty -= qty;
        _items.Add(new CartItem(product, qty));
    }
}

public class Product
{
    public int StockQty
    {
        get { return _stockQty; }
        set
        {
            _stockQty = value;
        }
    }
}

A clean simplistic shopping cart class. But life as a developer is never this clean and simple. In fact, the customer just came with a new Notification rule, specifying that:
“If StockQty drops below 5, then send a notification email to the Purchasing Department to restock the product.”

So we’re going to carry out that rule whenever the StockQty property is set (line #17). So what are we gonna need? Firstly, you’ll obviously need an INotificationService in the Product class, and the ShoppingCart is going to supply that, all the way from the top where you meet your IoC container.

At this point, you would not normally think of AOP. You would instead employ a more conventional approach by rearchitecting your domain structure. You use the good old Dependency-Injection, and introduce double-dispatch pattern around your methods.

public class ShoppingCart
{
    public void AddProduct(Product product, int qty,
                    INotificationService notifier)
    {
        product.ReduceStock(qty, notifier);
        _items.Add(new CartItem(product, qty));
    }
}

public class Product
{
    public void ReduceStockQty(int qty, INotificationService notifier)
    {
        _stockQty -= qty;
        if(_stockQty < 5)
            notifier.Send(Notice.Restock, this);
    }
}

So we changed the StockQty property into a method so we can inject a new dependency, which is passed all the way through shopping-cart up to the top, which depending on your object structure, may be quite deep. You have to make the same change to all places that use the StockQty property to accommodate the new dependency. This is an example of one simple change that make a great impact to the source code.

There’s no problem with this approach, we use this pattern everyday. But let’s now shift our thinking a little bit.

The main drawback of this approach is pollution. Let’s ask ourselves: does this piece of code really belong here? It doesn’t seem right to me. What’s a warehouse purchasing policy doing in a Product class? It is completely unrelated to the business of putting a product into your shopping trolley. And why do we need an INotificationService to use a shopping-trolley anyway? We certainly don’t send any notification email when you chuck a product into the trolley, but the service is just there to cover a specific edge-case scenario that might or might not happen somewhere down the line of the executing flow. If it only happens occasionally, why do we have to pass the notification-service every time? That seems to put a lot of unnecessary garbage to our otherwise clean code.

In typical projects, these edge-case-scenarios are usually quite plenty. There are usually a vast number of combinations of all different possibilities that we need to cater for, e.g. apply extra tax if the customer is within certain countries. Our code starts to look like transaction-scripts of various if-else conditions. Our classes are becoming less and less about shopping-carts and products; and more and more about different bits and pieces of all unrelated concerns, glued together to cover all possible basis.

What about all other notification alerts? Every time the customer define a new notification-template, we need to open our application source-code, look in our domain classes where we can fit the logic in, and implant the notification condition right there, and rewire all the required dependencies. We do that for each of our notification rules, and the whole notification policy is those pieces of logics scattered all over the source-code. Every time we define a new one, we need to remodify our domain source-code again. Each of our classes now has a lot more than one reason to change. Any class can change any time for any reason, and none of them can seem to escape from it.

Say Hello to SheepAOP

Let’s see an alternative way of implementing the same requirement. Let’s rewind back to the start.

public class ShoppingCart
{
    public void AddProduct(Product product, int qty)
    {
        product.StockQty -= qty;
        _items.Add(new CartItem(product, qty));
    }
}

public class Product
{
    public int StockQty
    {
        get { return _stockQty; }
        set
        {
            _stockQty = value;
        }
    }
}

These are our classes when they were still neat and clean. Everything about shopping-cart and product, and nothing else. So now, what’s the first thing that we’re going to change on these classes?

Right, the answer is nothing. We are not going to touch these classes. They already do all they’re meant to do, so leave it that way, keep them clean and simple, and don’t pollute them with any other garbage.

Instead, we are going to create a new class, let’s call it WarehouseNotificationAspect.

public class PurchasingNotificationAspect: IAspect
{
}

This class can be defined completely separate from your actual classes. Anywhere you want. You can even place this in a separate project, let’s say, Sheep.NotificationPolicy project, if you like.

Now let’s define a “pointcut”. If you’re not familiar with the terminology, don’t worry we’ll get there in no time. For now, you only need to know pointcut as a “criteria to search within your source-code”. In our case, we want to target the setter of our “Product.StockQty” property, so let’s write our pointcut for that.

[RegisterPointcut]
public static void SetProductPointcut(PointcutRegistry reg)
{
    reg.AddCurrentAssembly()
        .Listen(r => r.Setter(p => p.StockQty));
}

Now that we have our pointcut, we can offer an “advice” to it. We can say: “when this ‘property is set’ (PropertySet), after ‘it’s done’ (OnExit), please ‘do this and that’”.

public void Init()
{
    Listener.PropertySet(SetProductPointcut).OnExit += (j, c) =>
    {
        if ((int)j.Value < 5)
            _notifier.Send(Notice.Restock, (Product) j.Instance);
    };
}

During compile time, SheepAOP will insert these extra logic at the end of the StockQty property, and save it to your dll.

Since this aspect class is just a normal POCO class, it means you can just manage this using your normal IoC container, so you will have all your dependencies sorted. The full source-code of our aspect becomes:

public class PurchasingNotificationAspect: IAspect
{
	[RegisterPointcut]
	public static void SetProductPointcut(PointcutRegistry reg)
	{
		reg.AddCurrentAssembly()
			.Listen(r => r.Setter(p => p.StockQty));
	}

	private readonly INotificationService _notifier;
	public PurchasingNotificationAspect(INotificationService notifier)
	{
		_notifier = notifier;
	}
	public void Init()
	{
		Listener.PropertySet(SetProductPointcut).OnExit += (j, c) =>
		{
			if ((int)j.Value < 5)
				_notifier.Send(Notice.Restock, (Product) j.Instance);
		};
	}
}

Your original ShoppingCart and Product classes remain untarnished, so you can unit-test them easily as a plain shopping-cart without having to worry about other unrelated concerns and depedencies. Similarly, you can unit-test your notification-policy in isolation by testing your notification-aspects.

Jargons

Let’s review our jargons.

  1. Pointcut: Search-criteria of what you want to influence with your aspect. We had a very simple pointcut in our previous example, but pointcut can be very sophisticated. I’ll give an example using a pseudo-code with a language we’re all familiar with: SQL.
    select from all [methods] where
    	(methods:
    		is public or protected &
    		Name like ‘Get*’ | ‘Find*’ &
    		Returns (all types:
    			IsAssignableFrom (Money or Number)) &
    		Declared in (all types:
    			namespace: is ‘Sheep.Domain.*’ &
    			Implements(type: Name like ‘I*Service’)) &
    		Args is (int id, ..., string *name, )
    	)
    

    We were selecting all methods where it’s public or protected, with a name beginning with Get or Find, returning any type assignable from Money or Number, declared within any type within the ‘Sheep.Domain.*’ namespace, and implements any ‘I*Service’ interface, with arguments of yada yada yada.

    We can search not only methods and property. We can even search a specific-line-of-code! Such as this one.

    select all [instructions] where
    	(field: Product.‘_stock*Qty’ &
    		type: int or double
    	) &
    	instruction: Executed within
    	(method:
    		Name(‘Change*’) &
    		Declared in type: ShopingCart
    	)
    

    Just to give an idea of what pointcut does, let’s see one in action. I need to use an example from Java, because quite frankly I could not find anything from .Net that is even remotely comparable to AspectJ. So here’s AspectJ on Eclipse IDE.

    PS: AspectJ is an ambitiously sophisticated AOP framework, and SheepAOP is no where near it in any possible way. But the maturity of AspectJ makes for an excellent example to give you a good idea about various AOP concepts.

    image
    (Image #1, AspectJ Pointcuts)

    Unlike anything on .Net, in AspectJ aspect is a first-level language construct. So see on the left pane, we have an aspect that declares an annotation using pointcut * Account+.*(..), i.e., all methods within Account class with any name and any arguments. The right pane instantly shows you that 3 methods are affected by this pointcut. These 3 methods are your croscutting concern that you want to target with your aspect. You can even visualise these pointcuts within the IDE.

    image
    (Image #2, AspectJ Pointcuts Visualisation)

    On the right pane, you see your pointcuts, and the main panel shows you how each of these pointcuts crosscuts through your source-code. Imagine the blue one as our Notification Policy. We can see various places where we put some specific logic to send notification emails based on certain conditions. We can create an aspect for this so we don’t pollute our source-code with anything that’s not related with the actual business of your application.

  2. Jointpoints: The “search result” of your pointcut. Those 3 methods on the right pane of Image#1, we can see our Pointcut matches with 3 jointpoints (the validate(), credit(int), and debit(int) methods)
  3. Advice: Once we have our pointcut, we can offer it some advices of how those pointcuts should change their behavior (i.e. logging, start-transaction, authorisation, etc).
  4. Aspect: We have our pointcut, we offer it some advices, we have an Aspect.Here’s another example from AspectJ of a complete Aspect.
    image
    (Image #3, AspectJ Aspect)We have a complete AspectJ aspect. We define a pointcut to target all public methods under Account class (with any name and arguments), and we offer it an advice that “before” you execute the method, please authenticate the “account”, where “account” is the owner (aka the ‘this’) of the method.

Different Flavours

There are few different ways we can do AOP:

  1. Code Generator
    e.g. T4, CodeSmith
  2. Dynamic Proxy
    e.g. (Castle DynamicProxy), Spec#, NAspect
    This is by far the most popular AOP approach in .Net, which is unfortunate as it’s also the most limited way of doing AOP of all. It can only be used for objects managed by IoC, then its virtual/interface requirement, no static-methods, etc, making it hardly useful for too many purposes.
  3. .Net Profiller API
    e.g. TypeMock Open AOP (CThru).
    .Net profiler API’s use in production environments is strongly discouraged, although how bad we’ll get punished for violating it still remains unclear.
  4. IL Weavinge.g. AspectJ, PostSharp, and SheepAOP
    This is the most popular approach outside the .Net circle.

Why Another One?

PostSharp is an excellent product and has done remarkably well over the years, but one of my primary reasons of my reinventing it with SheepAOP (apart from to offer an open-source alternative) is down to the difference in style. PostSharp puts a huge emphasize on the use of .Net Attributes. The problem of Attributes in AOP is that the attribute itself becomes the repetitive crosscutting concerns. In contrast, SheepAOP firmly sticks on the well-known AOP pattern and terminologies using pointcuts, jointpoints, and advices, although the use of attribute will also be supported soon.

(.. more about SheepAOP in part 2)

Summary

SheepAOP is an open-source AOP framework, still in its early inceptions, that aims at bringing the classic AOP style and patterns to the .Net audience. The framework uses IL weaving (thanks to Mono.Cecil) to inject croscutting behaviours during compile-time.

In this post, we’ve discussed about how aspects can be used to help everyday’s domain-driven applications, beyond the highly clichéd transactions and logging.

The next post (part 2) will cover the basics of using SheepAOP.

The SheepAOP project repository and source-code of this post can be found in Codeplex: http://sheepaop.codeplex.com/

Should Domain Entity Be Managed By IoC?

One question that has always been puzzling people when starting doing Domain Driven Design is how a domain entity can talk to repositories or services controlled by IoC. Particularly if those entities are (and usually they are) loaded from ORM like nHibernate. There are a lot of controversy in DDD of whether a domain entity should depend on repositories or services at first place. First, a logic that requires dependency to repositories or services indicates that it is cross-aggregate. And the basic principle is, a logic that crosses aggregate boundary should NOT live in domain entity. It should live in services, and no domain entity should be aware of it. However, in reality, most except the simplest domain logics require external services. For example, a Sales entity is responsible of calculating the payable price. And in order to do so, it needs to figure out the discount, which then involves a business-rule-engine. Hence dependency from Sales domain to BRE service. So I think the question should not be about whether an entity should depend on services. It is the fact that we have to accept that more often than not, domain entity will absolutely need services. Without it, you will most likely end up with Anemic Domain Model, which at extreme level can be very very bad based on my experience. Now back to the question: how the domain should get hold of the services, particularly if the creation is not within our control (e.g., from ORM)? Apparently this has been a regular topic in Alt.Net and DomainDrivenDesign discussions that is always brought up every 1 week or two. Some suggestions given to me by quite few people, like Alasdair Gilmour, Larry Chu, et al, have given me a new insight that I have never expected before. IoC is not only about Services. It’s also about domain entity. Out of various approaches that Larry pointed out, there are generally 2 viable solutions to solve the dependency of domain-entity without tying it up with infrastructure detail. The first approach is to leverage interceptor. If you use nHibernate, Billy McCafferty shows how we can inject DI container from nHibernate loader interceptor. My response to it, I don’t like the idea of injecting DI container to the entity. But the similar approach can be used to inject the dependencies (instead of the container) into the entity. Unity container has an elegant solution for this kind of scenario using BuildUp method. You simply have to register your *domain entity as one of IoC services*. Hence the title of this post. There is currently no similar functionality in Spring.Net or Castle Windsor. But it’s pretty straightforward to do it ourself. What we need is a custom Dependency attribute, and decorate entity’s properties with it to mark as injectable dependency:

public class Sale
{
private ICustomerRepository customerRepository;

[Dependency]
public ICustomerRepository CustomerRepository
{
set {this.customerRepository = value;}
}
}

And write the NHibernate interceptor to introspect entity’s properties that are marked with the attribute, and resolve it from IoC container:

public class DepdencyInterceptor : IInterceptor
{
public bool OnLoad(object entity, object id,

object[] state, string[] propertyNames, IType[] types)
{

// Use “setter injection” to give objects’s dependency
// for each property marked with Dependency attribute

foreach (PropertyInfo prop in entity.GetType().GetProperties())
{
if (prop.CanWrite &&
prop.GetCustomAttributes(typeof (DependencyAttribute), true) != null)
{
object dependency = IoC.Resolve(prop.DeclaringType);

prop.SetValue(entity, dependency, null);
}
}

// Even though we gave the object it’s dependency, return
// the fact that we didn’t modify the persistent properties
return false;
}

// … All other methods of IInterceptor
}

Last, register the interceptor into NHibernate session manager:

NHibernateSessionManager.Instance.RegisterInterceptor(new NHibernateDepdendencyInterceptor());

The main drawback of using nHibernate interceptor, is that it’s limited to inject dependency to entity that is publicly accessible by its aggregate root. But I personally am not too concerned about that. I will think twice if I need to push dependency to inaccessible entity of an aggregate at first place. Because, IMO, the dependency of entity in the aggregate is the dependency of the aggregate root as a whole, at least from TDD point of view. It will be difficult to test-drive the aggregate root otherwise, and if that is the case, IoC-ORM integration will be the last thing I am worried about. The second approach, particularly if you don’t use nHibernate, is by using bytecode instrumentation. For instance, using post-compilation AOP, like PostSharp, to mangle the entity’s constructor to resolve its depdendencies (decorated fields/properties) from the IoC. This is by far the most powerful solution that can solve all possible cases. It is also ORM agnostic. This approach applies with most kinds of ORM, Sql-mapper, or even without ORM. The drawback of this approach, or rather the drawback of code-mangling AOP in general, is that it involves too much dark magic that makes things less clear to follow, and can be very difficult to debug. For this reason, dynamic proxy AOP is generally favorable over code-mangling. Dynamic proxy, unfortunately for our purpose, is not an appropriate option. Many IoC containers, mostly in Java, support the second approach out of the box. But I am not aware of any similar functionality in Windsor, or most .Net IoC framework in general. So we will need to get our hand a little bit dirty with PostSharp.