Simon Ince's Blog : AOP

Dependency Injection is Dead!

simonince — Mon, 30 Jun 2008 23:10:00 GMT

Long live “Dependency Resolution”!

OK, so I’m not really serious – but I got your attention right? Truth is, I personally love Dependency Injection, but that doesn’t mean it isn’t without its flaws. The Service Locator pattern is often touted as Dependency Injection’s nearest rival, so let’s very briefly examine some of the characteristics of each of these to see what works and what doesn’t.

What is great about these patterns?

It is hard to condense my enthusiasm into just a few bullet points! I’m also sure I’ve missed some, but just to get our minds in sync;

1. Testability; the loose coupling of your implementations means you can easily substitute mock classes, enabling your tests to focus on a single “unit”. You can also supply different implementations to allow testing at all (e.g. replace the calls to HttpContext.Current when you have no HttpContext).

2. Design approach; enforcing loose coupling helps to encourage good design. It helps to shield consumers from the service’s implementation, enabling you to swap implementation if necessary.

3. Configuration; there is often a big push towards highly configurable containers, both from the point of view of behaviour and their contents. This gives systems a feeling of agility, and the ability to adapt to different deployments or reuse in future systems.

4. Object lifetime management flexibility; objects can be cached, be a singleton, or be short lived – all controlled through configuration.

What is wrong with Dependency Injection?

There are some potentially painful issues with DI;

1. I find it counter intuitive that often some object somewhere needs to remember to “Build Up” an object. In other words, the chain of iterating over objects to fulfil their dependencies needs to start somewhere. This can be abstracted into HttpModules, framework code, and so on, but I still don’t like this. An object’s consumer shouldn’t need to know that X must be done before Y will work if at all possible.

2. When using property injection you generally need to mark your dependencies as public. This can seem counter intuitive, and certainly limits some use cases. Constructor injection can help here though.

3. Reflection; most (perhaps all?) Dependency Injection containers rely on some extent on Reflection – dynamically inspecting objects and determining their dependencies. I know there are optimisations out there for this, but the fact still remains that this can be an overhead.

4. Object chains can become quite large. If they’re needed this is no problem, but what if they’re not? Consider this code;

public class Chain

{

[CreateNew]

public Customer PrimaryCustomer { get; set; }

[CreateNew]

public Partner Partner { get; set; }

[CreateNew]

public ProductCatalogue Catalogue { get; set; }

[CreateNew]

public AddressLookupService AddressLookup { get; set; }

public string GetPrimaryCustomerName()

{

return PrimaryCustomer.Name;

}

public class SecurityService

{

[CreateNew]

public LoginProvider Login { get; set; }

[CreateNew]

public RoleProvider Role { get; set; }

[CreateNew]

public TraceProvider Trace { get; set; }

[CreateNew]

public AuditService Audit { get; set; }

}

OK, so it isn’t meant to be nice code, so please don’t flame me J. Still, you see the point? If all I want to do is call GetPrimaryCustomerName, and all that uses is one single dependency, my container will still have created instances of all my other types and populated the dependencies of my Chain object... and of course done the same to all the dependent objects. This could quite easily lead to an increase 10-fold in needless object creation and initialisation! “Use a singleton” I hear you say – sure, if applicable. But why use a pattern that has an enormous design impact on my code purely to reduce object creation just because my DI container is doing something slightly crazy? And even if I’m not creating objects, I’m still resolving their references.

What is wrong with Service Locator?

My main bug-bear with Service Locator is that it permeates throughout all my code. And most importantly, every object I write must know about the Service Locator in order to be able to fetch its dependencies.

Consider the following code adapted from the example above;

public class Chain

{

public string GetPrimaryCustomerName()

{

Customer primaryCustomer = ServiceContainer.Resolve<Customer>();

return primaryCustomer.Name;

}

This is must nicer – but it does mean my Chain class needs to know how to get hold of a Customer. Is this really so different to just creating a new one? Obviously you get the configurability of the Service Locator, but the separation of concerns is wrong in my opinion.

I should point out at this point that some clever people I know actually positively like this approach – they want to be explicit about fetching services and working with them. I see their point, and guess this comes down to personal preference, but the key is, if you like this approach chances are you don’t like DI at all – so this article is hopefully still of interest!

Lazy Dependency Resolution

So can’t we get the benefits of Dependency Injection and Service Locator without some of the drawbacks? I hope so; enter “Lazy Dependency Resolution” (which I already seem to keep abbreviating to just “Dependency Resolution”).

This is actually nothing new; I’ve just given it a name that sounds appropriate, having found a use for a new framework I’ve been playing with. Really, this is an approach cobbled together from various ideas and sources, and some similar ideas flying around “out there” on the web, but then that’s where all the best patterns start I think!

With the advent of static weavers that allow us to intercept calls using Aspect Oriented Programming techniques (see my previous article), we suddenly have an opportunity. The fact of the matter is that the Service Locator pattern does pretty much everything your average DI framework does, except that the service consumer needs some knowledge about how to call the Service Locator. Well, if we pull that concept out of our consumer classes and stuff it into a shiny new Aspect, what do you get? I think you get an implementation of a “Lazy Service Locator” that isn’t tightly coupled into the service consumer.

Enough talk, show me the code!

An Example with PostSharp

I’ve chosen to use PostSharp here as I’ve been playing with it a bit recently, but the idea is based on the concept of static weavers in general. If you want to know why this matters, read my previous article! </shameless-plug>

Quick Disclaimer: Note that this sample is really really rough-and-ready. It is not meant to be neat and tidy – it is just showing an alternative approach that I like. The reality is that I think some of the AOP libraries could help a bit by providing alternative interception models, support for explicitly only targeting properties a little more easily, or better ways of manipulating arguments and return values.

Anyway, for the simple demo we need two classes that must be loosely coupled; a consumer and a provider. The consumer consumes the provider... so to keep this dependency nice and flexible we’ll use an interface for our provider (so we could mock it if we liked, or switch implementations, etc).

public interface IProvider

{

void PrintId();

}

I told you this was going to be a simple example J

Next we need a consumer class that makes a call to an IProvider implementation;

public class Consumer

{

public IProvider Provider { get; set; }

public void DisplayInfo()

{

Provider.PrintId();

}

As you can see, we simply declare that we need an IProvider using a property here; we don’t specify where we get this from, or what concrete implementation we’re using. This matches how many Dependency Injection frameworks string objects together. Next, let’s have a concrete IProvider implementation (although we could have many different implementations if we liked);

public class ConcreteProvider : IProvider

{

private Guid _id = Guid.NewGuid();

public void PrintId()

{

Console.WriteLine(String.Format("My ID is {0}.", _id));

}

So what I want to be able to do now is call my Consumer class in a completely transparent way, avoiding calls to build the object up, or fetch it from a factory, etc;

public class Program

{

static void Main(string[] args)

{

Consumer consumer = new Consumer();

consumer.DisplayInfo();

}

OK, build it, run it... oh wait, we got a NullReferenceException because the Provider property is null.

Somehow, then, we want to tell our Consumer class which IProvider implementation it should be using. Well consider the following Aspect code;

[Serializable]

public class DependencyResolutionAspect : OnMethodInvocationAspect

{

public override void OnInvocation(MethodInvocationEventArgs eventArgs)

{

eventArgs.ReturnValue = ServiceContainer.Resolve(

eventArgs.Delegate.Method.ReturnType);

}

What this is doing is inspecting the declared return type of the method call we’re currently intercepting, and then looking up an implementation in a Service Container to return to the caller. This Service Container could be a facade to any number of registry techniques, so I’ve not included the code. Of course, this means it might return a singleton instance, a new instance, a mock, a concrete live implementation – all the configurability of Dependency Injection or Service Locator remains.

We then simply apply this aspect to our Consumer class’ properties using an assembly-level attribute;

[assembly: DependencyResolutionAspect(

AttributeTargetTypes="PostSharpDR.Consumer",

AttributeTargetMembers="get_*")]

Of course, there are other ways to apply aspects, but this seemed the quickest and simplest sample. Note that I’m filtering for methods that begin with “get_”, which is how .NET compiles the “getter” for a property.

This now means my application code can run as we wanted – assuming the Service Container is suitably initialised. I’ve chosen to do this in code here, but of course this could easily come from configuration;

public class Program

{

static void Main(string[] args)

{

ServiceContainer.Register<IProvider>(new ConcreteProvider());

Consumer consumer = new Consumer();

consumer.DisplayInfo();

}

As if by magic, our application now works.

One unpleasant implementation detail is that we effectively have a property that does nothing on our Consumer class. In fact, code that assigns to this property will compile, but is counter-intuitive at run time as the value you pass in will never be passed out again from the getter! Therefore, consider the following aspect instead;

[Serializable]

public class DependencyResolutionAspect : OnMethodInvocationAspect

{

public override void OnInvocation(MethodInvocationEventArgs eventArgs)

{

object existingImplementation =

eventArgs.Delegate.DynamicInvoke(

eventArgs.GetArgumentArray());

if (existingImplementation != null)

eventArgs.ReturnValue = existingImplementation;

else

eventArgs.ReturnValue = ServiceContainer.Resolve(

eventArgs.Delegate.Method.ReturnType);

}

* Note this doesn’t support value types correctly! Again, I’m trying to keep my code simple

Now our aspect will invoke the property that it is intercepting, and return the property’s existing value if it is non-null. If the current value of the property is null, we return an implementation resolved via our Service Container. Of course we could do this in a number of ways (e.g. intercept the set call too, and use a private Boolean field that flags whether a manual set has occurred). This now means we can override the Dependency Resolution behaviour – something that could be really useful for testing if we don’t think we need (or want) to spin up a configured Service Container.

Therefore the following code in a unit test will always use our MockProvider, without changing how any aspects are compiled, and without worrying about whether a Service Container has been initialised or not.

Consumer consumer = new Consumer();

consumer.Provider = new MockProvider();

consumer.DisplayInfo();

Simple huh? The last thing I should mention is that caching the resolved service would probably be worthwhile – because at the moment we’re calling to the service container on every access to the property. This is easy to fix though, so I haven’t bothered for the sake of this post J

Good, Bad, or Ugly?

I think the best way to consider how this stacks up against the alternatives is to compare against what I see as the down-sides to DI and Service Locator;

1. Responsibility for building up objects. This responsibility has now been pulled out into an Aspect; ideal for AOP, this is a cross-cutting behaviour that I can apply to many methods using configuration statements. My code stays clean, my concerns are separated, and my developers, testers, and architects are all happy (oh, and the flying pigs are too).

2. Public dependencies. I don’t see any reason why I couldn’t modify the IL for protected and private properties too. We’d just need to be a little careful of this – is a developer really expecting a private object to be resolved by an apparently “external” component? Oh, and I don’t support constructor injection in this post, but I’m sure we could.

3. Reflection; Doh!! See comments below.

4. Large object chains; This is perhaps the best bit; as all resolution is done in a “lazy” fashion, only those paths through the object chain get created or resolved. Hey presto, no over-the-top object instantiation, yet no loss of benefits from a Dependency Injection style approach.

What don’t I like?

One issue is that really this needs a static weaver to achieve our aims – so many frameworks (Spring, the Enterprise Library, and so on) are out of the picture... for now.

[Edit: The following paragraph is my original content, but it turns out is not a completely accurate picture; be sure to check out Gael's comments below - approx the 27th comment down! Simon]

Secondly, the fact that my implementation using PostSharp still relies on reflection is a shame, and this is down to how the framework functions; really I’d like to edge this out of the door to maximise the benefits of the pattern, but I don’t fancy writing my own IL parsing cleverness! I haven’t had time to flesh out my ideas around this yet, but if I ever do I’ll be sure to post them!

Conclusion

Well, what do you think? Let the debate begin! I think this is a very simple evolution of Dependency Injection that removes some of the common objections to it – and hence could increase the audience that benefit from what I consider a good pattern to encourage good software design.

Be aware I haven’t used this in a real implementation yet... I’m floating a concept for discussion, so feel free to chip in.

Aspect Oriented Interception

simonince — Tue, 24 Jun 2008 12:38:00 GMT

Have you used Aspect Oriented Programming (AOP) or Policy Injection? They’re pretty much the same thing. If you haven’t, I’d highly recommend doing some reading, as I believe it is a Software Engineering practice that has moved out of the “fashionable” and into the “enterprise”. For separation of concerns it is a fantastic paradigm.

I’ve done a number of demos now, on topics like the Web Client Software Factory and how it integrates with the Enterprise Library, and when I get to the bit that I add an attribute to my code like this;

[Log]

public void SaveCustomerRecord()

{

// ... implementation

}

... and click run, only for the attendees to see all the logging happening as if by magic, there is often an impressed intake of breath. There are of course other ways of applying “aspects”, using configuration for example, but this is a quick and easy example.

I’m going to assume you’re aware of the basic principles of AOP – if you’re not, try having a read of some of these resources;

· Wikipedia’s definition of Aspect-Oriented Programming

· Spring .NET’s AOP Chapter

· Type AOP into a search engine (Live Search, obviously J)

To get a basic understanding, make sure you know about aspects, targets, join points & point-cuts, advice, and introductions. One often overlooked one you should know about is weaving.

Weaving Aspects

Weaving is all about adding the calls to your aspects into the existing code. So imagine we have a method that looks like this (* note: excuse the terrible code, it is only meant to be illustrative!);

[Log]

public void SaveCustomerRecord(int id, Dictionary<string, object> values)

{

Customer customerRecord = new Customer();

customerRecord.ReadFromDatabase(id);

customerRecord.UpdateDetails(values);

customerRecord.Save();

}

... then adding the calls to “Log” might effectively change my code to look like this;

public void SaveCustomerRecord(int id, Dictionary<string, object> values)

{

try

{

Logger.LogMethodEntry();

Customer customerRecord = new Customer();

customerRecord.ReadFromDatabase(id);

customerRecord.UpdateDetails(values);

customerRecord.Save();

}

catch (Exception e)

{

Logger.LogException(e);

throw;

}

finally

{

Logger.LogMethodExit();

}

I’m sure you can see the difference; we now log entry to and exit from the method, and any errors we encounter. So something must alter the code to do this, right?!

Well, yes! That is, either the code is changed, or the call is intercepted and rerouted.

It turns out there are a few ways of doing this, and we’ll cover what these are below, seeing the differences as we go.

Interception Mechanisms

1: Interface Proxy

The “interface proxy” method looks like this;

In this scenario, the “target” class must implement an explicit interface. The runtime can then create its own runtime implementation of this interface that simply intercepts the calls, processes the relevant aspects, and then (if applicable) calls onto the real target object. An example of this using Spring .NET is below;

public interface ITarget

{

void DoSomething();

}

public class Target : ITarget

{

public void DoSomething()

{

Console.WriteLine("I'm doing something...");

}

public class Program

{

public void Run()

{

ProxyFactory factory = new ProxyFactory(new Target());

factory.AddAdvice(new LoggingAspect());

ITarget target = (ITarget)factory.GetProxy();

// do it!

target.DoSomething();

}

Here we can see that our Target class implements ITarget, and that when we retrieve a proxy to it, we actually get a dynamically created implementation of ITarget, that calls LoggingAspect and then passes the call onto our real Target class. Note that the configuration of the factory, when we add advice, could be done in configuration.

So this is a really nice way of doing things, but some people don’t like having to have an interface for every class they want to intercept. And I don’t blame them – if you use an aspect for logging, you might want it on every single class! That’s a lot of interfaces...

This is the mechanism that most of the .NET AOP frameworks use, to some extent; Spring .NET, the Enterprise Library Policy Injection block (although the docs tell us the PIAB is not an AOP framework, it is close enough for this topic), Castle Windsor’s Dynamic Proxies...

2: Remoting Proxy

Our next option is to use some cleverness built into the Remoting infrastructure in .NET.

I’m not going to go into the detail (if you really want to know, there’s some info here), but basically this allows us to intercept calls to any method on our Target object. Of course, this doesn’t come free. In fact, it down right hurts – we have to inherit from MarshalByRefObject, and there is likely to be a performance hit. Let’s see an example using the PIAB;

public class Target : MarshalByRefObject

{

[LogCallHandler]

public void DoSomething()

{

Console.WriteLine("I'm doing something...");

}

public class Program

{

public void Run()

{

Target target = PolicyInjection.Create<Target>();

// do it!

target.DoSomething();

}

Notice a few things in this code; firstly, we must inherit from the dreaded MarshalByRefObject (which of course prevents us from inheriting from anything else our code might find more useful). Secondly, note that I’ve chosen to use an attribute (“LogCallHandler”) on a method to apply an aspect to the target. Some people hate this (mainly because of the coupling between target and aspect) – you can do it in config if you wish. Lastly, note that we create an object using an overload of PolicyInjection.Create that supports using a class with no interface (or the alternative Wrap method).

Again, many frameworks support this approach.

3: Inheritance Proxy

The third option is an inheritance proxy, characterised by the following diagram;

Why, when the two above methods can do everything we need? Gotcha; they can’t do everything we need. There’s actually a big hole in what we’ve already covered. Consider the following code, adapted from the example in option (2) – and look carefully;

public class Target : MarshalByRefObject

{

public void DoSomethingFirst()

{

// pass on the call

DoSomething();

}

[LogCallHandler]

public void DoSomething()

{

Console.WriteLine("I'm doing something...");

}

public class Program

{

public void Run()

{

Target target = PolicyInjection.Create<Target>();

// do it!

target.DoSomethingFirst();

}

All I’ve done is to introduce a new method; now my Program class calls “DoSomethingFirst”, which in turn calls “DoSomething”. This second method is the one that has the logging aspect applied to it.

But of course, our aspect is invoked by a Proxy, and when DoSomethingFirst calls to DoSomething, it does it using the “this” keyword (implicitly). Therefore this call is not going via the proxy, and therefore no aspects get invoked. Owch! So my AOP mechanism only works when calling to a different object!

Now this isn’t a show-stopper, as long as you understand this behaviour, but it is a bit of a pain, which is why the inheritance proxy approach can be useful.

OK, now we need to switch frameworks as the PIAB doesn’t support inheritance proxies... let’s use Castle Windsor’s DynamicProxy2, tweak our example to mark its methods as virtual, and get rid of the MarshalByRefObject base class;

public class Target

{

public virtual void DoSomethingFirst()

{

// pass on the call

DoSomething();

}

public virtual void DoSomething()

{

Console.WriteLine("I'm doing something...");

}

public class Program

{

static void Main(string[] args)

{

ProxyGenerator factory = new ProxyGenerator(

new DefaultProxyBuilder());

Target target = factory.CreateClassProxy<Target>(

new LoggingInterceptor());

// do it!

target.DoSomethingFirst();

}

This means our reference to what we think is a Target class is now actually a dynamically created subclass of Target... perhaps something like this (note: I’m massively simplifying intentionally);

public class GeneratedTargetSubClass : Target

{

public override void DoSomethingFirst()

{

AOP.CallBeforeAspects();

base.DoSomethingFirst();

AOP.CallAfterAspects();

}

public override void DoSomething()

{

AOP.CallBeforeAspects();

base.DoSomething();

AOP.CallAfterAspects();

}

Now, immediately our Target class calls from one of its members (say DoSomethingFirst) into another (such as DoSomething), the call will go through our generated subclass, and hence our aspects will be executed successfully.

4: Modified IL

The last, and probably most impressive approach, is to literally compile the aspects into the IL. IL is “intermediate language”, basically what all .NET code (VB.NET, C#, J#... anything) compiles to, and is pretty much equivalent to Java’s bytecode. Speaking of Java, in Java-land AspectJ can compile aspects into the bytecode using a post-processing step.

In .NET, there are a couple of options for doing this – namely PostSharp and AspectDNG (based on Cecil). For PostSharp, the third and (hopefully) final Release Candidate was recently announced, so I thought it was high time I had a look.

So in our fourth case the diagram looks like this;

This clever approach lets you write aspects that are compiled into the IL in a post-processing step. For PostSharp, the installer also hooks into MSBuild so that it all happens automatically if you reference the PostSharp assemblies. We can specify aspects using attributes again, so have a look at the following code;

public class Target

{

[LoggingAspect]

public void DoSomething()

{

Console.WriteLine("I'm doing something...");

}

public class Program

{

public void Run()

{

Target target = new Target();

// do it!

target.DoSomething();

}

The first thing you should notice is that there is no need to generate a proxy, wrap a proxy, intercept calls using a remoting infrastructure, or anything else. Just create a Target and call its method. That’s because the [LoggingAspect] attribute is weaved into the main code for DoSomething at compile time.

Our LoggingAspect implementation could look something like this;

[Serializable]

public class LoggingAspect : OnMethodBoundaryAspect

{

public override void OnEntry(MethodExecutionEventArgs eventArgs) ...

public override void OnExit(MethodExecutionEventArgs eventArgs) ...

public override void OnSuccess(MethodExecutionEventArgs eventArgs) ...

public override void OnException(MethodExecutionEventArgs eventArgs) ...

}

If we now look at a sample of the code that exists in our compiled .NET assembly, you might be surprised how little it looks like the code we wrote!

PostSharp has “weaved” (how appropriate does that term seem now you see the code?!) calls to our aspects into the DoSomething method. We could also have applied our attribute at the assembly level – semantically equivalent to “intercept all calls to methods that start with a Y in this assembly”, for example.

Perhaps the biggest issue here that doesn’t apply to the other approaches is that you cannot dynamically apply or remove aspects using configuration, after compile time. But then, you can build config into your aspects – so a logging aspect may have an on/off switch for example. This is not quite the same, so think about it carefully if this matters to you.

What I really like is that I don’t need some kind of factory to create or wrap my objects, and that my code is fixed into the assembly – which surely should perform well? I put a question mark here because PostSharp does still use reflection, so I’d be keen to see some comparisons... but still, it isn’t proxying every call. And of course the aspects will be applied across all calls – not just those from a different object!

Conclusion

I hope that’s been a useful little look at how some of these AOP frameworks (*) work in the background. The key takeaway is that there are differences in behaviour that can affect you when using these frameworks. There are also differing levels of abstraction and decoupling – so choose carefully!

I personally love the idea of compiling aspects into the IL. In fact, I’d love to see making this kind of compiler-level extension easier in .NET some day. I can’t quite get my head around how it would work, but I wonder if lambda expressions and LINQ might work together nicely to help here in some way... more thought required I think.

One important point to note is that I have deliberately not compared the frameworks against AOP principles, the quality of their point-cut language, and so on... if you’re interested in those, do some reading and let me know what you think! A good starting point is the AOP Alliance.

Anyway, happy point-cutting!

* yes I know some of them don’t claim to be AOP frameworks, but they’re frameworks that help with AOP, or are approaching AOP, that’s good enough for me J

Useful Links

Check these out for some more information... and there are many more too!

· The PostSharp home page

· The AspectDNG home page (and Cecil)

· Tom Hollander’s original PIAB announcement

· The Enterprise Library (you want versions 3+ for the PIAB)

· The Castle Project (for Castle Windsor etc)

· The Spring Framework for .NET

Also, after writing 99% of this article, I found a great little post by Ayende comparing approaches to AOP in .NET – worth a quick read.