So, here’s the final part of my Interception / Behaviours / AOP with Unity thread… I discussed (at length) an example problem space we have in my previous post; I want to give an example solution which provides very good encapsulation to the client code using Interceptors. Carrying right on then - we already have … Continue reading AOP with Unity – Part 3
AOP with Unity – Part 2
In my previous post I gave some examples of how Unity implements behaviours (or interceptors) typically using a form of the Decorator pattern. Most of the examples you see of where you use these behaviours are for classes you yourself own, and thus can put attributes on the methods or whatnot. There is, however, another … Continue reading AOP with Unity – Part 2
Using AOP in .NET
I’ve been using Unity Interceptors recently, which to me are a form of AOP (Aspect-Oriented Programming). This is a cool way to put cross cutting concerns on your code in a readable, reliable and reusable manner. Typically you decorate your classes with attributes or such in order to inject code at run-time. Some typical examples … Continue reading Using AOP in .NET
Making Unity mappings easier with Reflection
Nothing really magical here, but I was playing around with Unity the other day – I wanted to do some dependency inversion – and got to thinking about how one generally implements their type mappings. There are usually two ways: - Do your mapping in a config file Use code-driven mappings i.e. in C# In … Continue reading Making Unity mappings easier with Reflection
The Dependency Inversion Principle
This is something that I read a while ago in the Agile Patterns & Principles book a while ago – in fact, first time I read it was a good 18 months ago. I tried using it in a project then, and was partially successful – but am now using it “properly” on my current, and thought it was worth blabbing a little about it.
Here’s a simple example of how you might currently have a simple two-tier system talk to each other: -
1: public class CustomerBll 2: { 3: DataAccessLayer.CustomerDal DataAccessReference { get; set; } 4: 5: CustomerBll () 6: { 7: DataAccessReference = new DataAccessLayer.CustomerDal (); 8: } 9: 10: IEnumerable GetCustomers () 11: { 12: // Uses DataAccessReference to load customers 13: // and return to caller. 14: } 15: }
You’ll notice that there’s a concrete reference between the two classes. This is often fine, but sometimes, you’ll want to abstract this relationship away (don’t you find that everything in computer science comes down to abstractions 🙂 and have an interface in between as a level of indirection. Why? Perhaps you have a number of concrete implementations and want to have some single piece of code that can act over any implementation. Or maybe (as I do in my current project) you want to mock your DAL and thus replace the “real” DAL with a stub that does stuff to help write your unit tests.
So, you create an interface on your DAL based on your DAL class, like so (note: it just so happens that Visual Studio has an “Extract Interface” refactor tool built in for exactly this sort of scenario): -
Then, on e.g. your Business Logic class, you perhaps have a constructor which by default uses the “real” DAL, and another which can take in a mock version or similar. Otherwise, your BLL class only ever talks to the interface. Great!
1: public class CustomerBll 2: { 3: ICustomerDal DataAccessReference { get; set; } 4: 5: CustomerBll () 6: { 7: DataAccessReference = new DataAccessLayer.CustomerDal (); 8: } 9: 10: CustomerBll (ICustomerDal dal) 11: { 12: DataAccessReference = dal; 13: } 14: 15: IEnumerable GetCustomers () 16: { 17: // Uses DataAccessReference to load customers 18: // and return to the caller 19: } 20: }
Except there’s a problem to this approach that’s both logical and physical – the placement of your interface. By putting it onto the DAL, the BLL still has to directly reference the DAL. It’s still physically tightly coupled to the DAL assembly; if you wanted to change it over, you’d theoretically have to redeploy both assemblies even though the BLL isn’t interested in the concrete implementation, only the interface.
How do we solve this problem? Using the DIP. This states that you effectively keep the interface – the contract – close to the client of that contract, rather than close to the server (implementation) of it. This is because when you think about it, why should a change in the physical implementation of that interface be closely coupled to the interface? Even worse, why should you be able to break the client simply by changing the server dll!?
So, you change the relationship like so:
So, now the business logic is closely related to the interface. You cannot deploy a change to the interface without redeploying the business logic layer client itself. However, there’s a catch… you may have asked yourself – how does the BusinessLogic get a reference to the real CustomerDal class? It doesn’t reference that assembly any more! So what do you do? There are a number of options. One is to have a third “controlling” assembly which references both the assemblies above and passes the concrete implementation at runtime into the business logic. This works great, but requires manual effort, and is really just writing boilerplate code to act as a factory injecting objects in.
A much more elegant solution is to use something like Unity, which is basically an object factory. You specify in your application configuration file what gets resolved to what e.g. ICustomerDal maps to CustomerDal. Then in your BLL, you simply tell Unity - “give me an object of type ICustomerDal”. This way, you never reference the physical implementation. You can mock up a fake Data Access layer in your unit tests. Your code is loosely coupled. It – just – works! 🙂
So what I’ve done compared in this final version of code is effectively take out the code which decides what object the ICustomerDal should be:
1: public class CustomerBll 2: { 3: ICustomerDal DataAccessReference { get; set; } 4: 5: public CustomerBll () 6: { 7: DataAccessReference = Framework.ObjectFactory.GetObject (); 8: } 9: 10: IEnumerable GetCustomers () 11: { 12: // Uses DataAccessReference to load customers 13: // and return to the caller 14: return null; 15: } 16: }
The “ObjectFactory” class above is a simple singleton class which acts as a facade over Unity (not that Unity is complex, merely that I want a single instance of the Unity container throughout the application):
1: public static class ObjectFactory 2: { 3: static UnityContainer container = new UnityContainer (); 4: 5: static ObjectFactory () 6: { 7: ConfigureUnityFromAppConfig (); 8: } 9: 10: private static void ConfigureUnityFromAppConfig () 11: { 12: var section = ConfigurationManager.GetSection ("unity") as UnityConfigurationSection; 13: section.Containers.Default.Configure (container); 14: } 15: 16: ///
The Cockney Coder 