ASP.NET MVC 3: Agnostic Inversion of Control

ASP.NET MVC has matured over the years and I’ve had the fortune to be able to do some development work recently on this. One of the first things I explored was to setup an Inversion of Control (IoC) container. One of the biggest benefits of using an IoC is to accommodate for the ease of unit testing using a mocking framework.

Anyways we use Castle Windsor on our project, but in theory we should be able to use any IoC framework.  I started to think about how to decouple the project from a specific IoC framework, so if we ever wanted to change to a different one, it would be easy and straightforward. Perhaps this is overkill in the real world, but would be a good exercise to go through.

Article: Microsoft Patterns and Practices

I came across a good article on MSDN that talks about the separation of concerns using Enterprise Library (now at 4.1), using the Object Builder framework and Unity Application Block for Dependency Injection/Inversion of Control, with examples of incorporating it into Model View Presenter (MVP) pattern.

With quite a number of open source frameworks (like Castle Windsor) out there that do these already, it’s refreshing to see that MS is churning out their own pattern frameworks for .NET Development.

Read article here!

Decorator Pattern with WCF and Castle Windsor

How do you extend a WCF Service that you cannot modify? Or even if you can modify it, should you? Consider the Open Closed Principle. Assuming that you can’t modify the existing service, but want to leverage existing service somehow from your new service, what should we do? That’s where the Decorator Pattern comes into the picture.

The Decorator Pattern is commonly used to modify or add additional behaviour to a class dynamically without modifying it’s current behavior.

Assuming we have an existing service, like so.