Archive

Posts Tagged ‘Dependency Injection’

Shaping up with Angular.js

November 30, 2015 Leave a comment

This is one the finest and free AngularJS webcasts I have seen so far . If you are new to AngularJS development and want to learn AngularJS but have no clue where to start then this is tutorial to go for.

https://www.codeschool.com/courses/shaping-up-with-angular-js .

Thanks to the guys at codeschool to make this fun driven tutorial which is so exciting to watch and learn. 🙂 ❤

Principles of Programming

January 20, 2012 1 comment

Great video tutorial about principles of programming.

Principles of Programming Part 1

Principles of Programming Part 2

Happy Clean Coding !!!

Why program against an interface ?

July 19, 2011 8 comments

I have done a lot of post regarding interface based programming and we have seen some good benefits of programming against an interface as compare to its concrete implementation. One of the best things it does it that it promotes SOLID design principles and allows us to have a level of abstraction or separation of concerns.

If you haven’t read my previous post about the benefits of interface I recommend reading them and here are some of those posts.

In this post I am going to show another benefit of using interfaces and that is how easy it is to add additional behavior (decorators) without changing the code. With interfaces you are able to provide nice extensibility point and keeping our code SOLID ( yes it is the big ‘O‘ in SOLID) and as usual Dependency Injection plays a key role in accomplishing the task with minimal effort.

Let’s start with a simple interface like this one.

ICustomerRepository.cs


public interface ICustomerRepository
{
   List<Customer> GetCustomers();
}

And let’s write the CustomerRepository class which implements this interface.

public class CustomerRepository : ICustomerRepository
{
   public List<Customer> GetCustomers()
   {
      return new List<Customer>
                {
                   new Customer(1, "Joe", "Blogg"),
                   new Customer(2, "John", "Doe")
                };
   }
}

And this is our client code that calls the CustomerRepository class, it’s a standard example I have used in most of my posts depicting a real world example of business layer calling the repository layer.

CustomerBl.cs

public class CustomerBl : ICustomerBl
{
   private readonly ICustomerRepository _customerRepository;
   public CustomerBl(ICustomerRepository customerRepository)
   {
      _customerRepository = customerRepository;
   }

   public List<Customer> GetCustomers()
   {
      return _customerRepository.GetCustomers();
   }
}

I will add a simple class diagram for people who love to see the class diagram,as I personally favor class diagram over code.

Customer Repository Injected into Customer Business Layer

As you can see nothing special, we are just using constructor injection in our CustomerBl so that through IoC I can decide which class will be injected into the CustomerBl as long as the class implements the ICustomerRepository interface (contract).

So far so good the code is running fine and it’s in production, your customer is happy and you feel good about it.

After some time the customer says that I want to do logging when this function is called and the first thing which comes to your mind is okay I will write a logging code in the CustomerRepository GetCustomers() method.

But wait lets put some thought into this. First as soon as you are modifying the CustomerRepository class you are breaking the Single Responsibility Principle as this class has now 2 reasons to change.

  • If the GetCustomers() method logic changes
  • If the logging mechanism changes

Lets think “does this logging really the CustomerRepository’s responsibility” and at the same time we don’t want to put the logging code into CustomerBl class as it’s not even its responsibility. And what about the logging it could change in the future.

So let’s abstract the logging responsibility into its own interface like this.

ILogger.cs

public interface ILogger
{
   void Log(string message);
}

And the class which implements this interface is

DebugLogger.cs

public class DebugLogger : ILogger
{
   public void Log(string message)
   {
      Debug.WriteLine(message);
   }
}

Here I have chosen a simple class which writes to the output window to keep the example as simple as possible and since we are implementing through interface we can easily change it into file based or database based logger using the Dependency Injection Principle.

Here is the interesting part as you can see from our ICustomerRepository interface that the CustomerBl class just care for this interface and has no knowledge of what the actual class does.

This gives us a good opportunity to implement a new class which has the same interface signature but does the logging and then calls our actual CustomerRepository class as is. With this philosophy nothing has changed and the new class would act as a proxy.

Hmmm let me show you the code and see if I can make more sense so I will create a new class called LogCustomerRepository which will implement the ICustomerRepository interface and will have dependency on it as well as on the ILogger interface.

LogCustomerRepository.cs

public class LogCustomerRepository : ICustomerRepository
{
   private readonly ICustomerRepository _customerRepository;
   private readonly ILogger _logger;
   
  public LogCustomerRepository(ICustomerRepository customerRepository,
         ILogger logger)
   {
      _customerRepository = customerRepository;
      _logger = logger;
   }

   public List<Customer> GetCustomers()
   {
      _logger.Log("Before the get customer method");
      var result = _customerRepository.GetCustomers();
      _logger.Log(string.Format("Total results found {0}", result.Count));
      return result;
   }
}

And an elaborated class diagram.

Log Customer Repository Injected into Customer Business Layer

Customer Repository Injected into Log Customer Repository
So as you can this class just decorates the CustomerRepository and it shouldn’t make any difference to the client code(CustomerBl) as both the class implement the same interface (contract).

Now only thing left is wire this up in our IoC and I am going to use Castle Windsor Installer to have a nice separation of the configuration from the actual container.

If you are not familiar with Castle Windsor installer class please read my previous post about it.

CustomerInstaller.cs

public class CustomerInstaller : IWindsorInstaller
{
   public void Install(IWindsorContainer container,
                       IConfigurationStore store)
   {
      container.Register(
         Component.For<ILogger>()
            .ImplementedBy<DebugLogger>(),

         Component.For<ICustomerRepository>()
            .ImplementedBy<CustomerRepository>(),

         Component.For<ICustomerRepository>()
            .ImplementedBy<LogCustomerRepository>()
            .Named("LogCustomerRepository"),

         Component.For<ICustomerBl>()
            .Named("CustomerBl")
            .ImplementedBy<CustomerBl>()
            .ServiceOverrides
            (
               ServiceOverride
                  .ForKey("customerRepository")
                  .Eq("LogCustomerRepository")
            )
      );
   }
}

This is the core of how registration and components works in Castle Windsor. The important thing to notice here is I am using named component registration as I want to make sure that when my CustomerBl class asks CastleWindsor to resolve for an implementation of type of ICustomerRepository it will return the LogCustomerRepository class instead of CustomerRepository and this way I am making sure that the decorators are invoked in the right order.

So in the ServiceOverrides method I am telling CastleWindsor that CustomerBl has a Dependency on ICustomerRepository and the name of the variable which is passed into the constructor is “customerRepository” and when you come across this variable then invoked the registered component which has been tagged as “LogCustomerRepository” rather than the default registered component CustomerRepository.

Although this syntax is very specific to Castle Windsor but the concept is quite uniform across all the IoC containers.

Let’s write a unit test to see how this all comes together.

UnitTest.cs

[TestClass]
public class When_using_CustomerBl
{
   private IWindsorContainer _container;
   [TestInitialize]
   public void Setup()
   {
      _container = new WindsorContainer();
      _container.Install(new CustomerInstaller());
   }

   [TestMethod]
   public void Should_be_able_to_get_customers()
   {
      var customerBl = _container
                        .Resolve<ICustomerBl>
                        ("CustomerBl");

      var result = customerBl.GetCustomers();
      Assert.IsTrue(result.Count > 0);
   }
}

And when I run the test it passes with the desired result and in the output window I do see the messages I expect.

Unit Test

As you can see from the Watch window that how these interfaces are resolved by Castle Windsor and how I am getting the correct type when I need it.

This way of decorating interfaces and creating decorators is a nice and easy pattern but it also gives us some insight into Aspect Oriented Programming as these decorators are merely cross cutting aspects.

For example we can easily create Logging,Security,Caching,Instrumentation etc decorators and Inject them with Castle Windsor.

Loosely Coupled Architecture

December 1, 2010 4 comments

In this post I will give you another interesting perspective into designing loosely coupled architecture. Lets first see what does Wikipedia says about Loose Coupling ..

  In computing and systems design a loosely coupled system is one where each of its   components has, or makes use of, little or no knowledge of the definitions of other   separate components.  

In some of previous post I showed how dependencies between components/services can be decoupled by interface (contract) and it is the contract each component cares about.It does not care how it is implemented and who has implemented it. Then we introduce IoC/Dependency Injection which determines which component will be used when any part of the system calls that interface. To decouple we simply have the interface passed to the constructor of the class and this is called constructor injection and same way you can have method injection as well.

As usual I will start with a basic example and see how we go from there.So for example you are writing a batch job or some piece of code which execute some Update to the database using an Id. (I know this sounds quite vague but very soon you’ll see what I am getting into).

So let’s see how it appears to our mind :-

public interface IDbTask
{
    void Execute(int id);
}

As a good architect you should always anticipate change.The code works fine but in future I am anticipating that the criteria will become more complex and I have to factor that in because the business is evolving.

Let’s say the criteria is id plus something more like if the date is Tuesday and the first name is like this or that ..blah blah ..you got the picture. Keeping this in mind I would create the interface contract as this ..

public interface IDbTask
{
    void Execute(IActionParameter param);
}

and for the first iteration this is how my interface IActionParameter looks like.

public interface IActionParameter
{
    int id { get; set; }
}

see at this point I am just defining the contract no actual implementation. So now the BA comes and says we need to add the date parameter and since we are doing real Agile we have to adhere to the open close principle i.e. we should not change the IDbTask nor the IActionParameter

But with the open close principle this class or interface can be extended ( remember extensibility). So we will go ahead and extend it.

public interface IDateActionParameter : IActionParameter
{
    DateTime Date { get; set; }
}

and just for the sake of it and to see the bigger picture a class implementing the interface would look like

public class DateActionParameter : IDateActionParameter
{
    public int id { get; set; }

    public DateTime Date { get; set; }
}

Now since DateActionParameter still implements the base interface i.e. IActionParameter we can still pass it as is and we didn’t change the signature of the execute method.

I know you might be thinking that we still have to change inside the code to factor the 2 parameters in your decision-making. Well may be or may be not ;-). I mean if you really want it like that,then there are much complex and sophisticated patterns to implement and this is the first baby step.

The fundamental thing is there has not been any brut force signature change and you are not breaking anything. You are extending it, hopefully you will also see how IoC/DI plays a big part on designing such components.

Lets see this in another more real life scenario like the repository layer, business layer, web service layer etc.Suppose you are implementing a simple Customer business layer and for easy illustration I am just going to show CUD i.e. Create, Update, Delete( and Read will come later)

public interface ICustomerBL
{
    void Update(ICustomer entity);
    void Add(ICustomer entity);
    void Delete(ICustomerActionParameter param);
}
 

As you can see it’s pretty simple all the interface and it’s actual implementation like Customer and CustomerActionParameter will be injected by IoC/DI and we are keeping everything clean.

There is no tight coupling and it has full extensibility , anything can be chop and change on the fly and still everything works.

If I have to test the Add method with a  fake object all I have to is implement the ICustomer interface and create it’s fake implementation.

So you might be thinking if everything is so cool and easy then why am i holding onto the Read and if you haven’t figured it out then here is the big deal with it ..(drum roll)… the problem lies in its method signature ..

public interface ICustomerBL
{
    void Update(ICustomer entity);
    void Add(ICustomer entity);
    void Delete(ICustomerActionParameter parameter);
    ICustomerDO Get(IActionParameter parameter);
    List<ICustomerDO> GetAll(ICustomerActionParameter parameter);
}

At surface it all looks okay and the ICustomerDO is supposed to be a domain object which might have a different properties or behaviour as compare to your database entity “customer” (it’s always a good design pattern to not expose your database entity directly to business layer,service layer or UI layer).

Now the real problem lies how do I new up this object with out hard coding it ?

You might say Oh ! that’s easy like in the previous post we will just use the constructor injection …hmmm good thinking but isn’t our constructor already preoccupied by this :-

public class CustomerBLICustomerBL
{
    private readonly ICustomerRepository _repository;

    public CustomerBL(ICustomerRepository repository)
    {
        _repository = repository;
    }

    public void Update(ICustomer entity)
    {
        _repository.Update(entity);
        // just for illustration
        // same for add and delete
    }

    public void Add(ICustomer entity)
    {
        _repository.Add(entity);
    }

    public void Delete(ICustomerActionParameter parameters)
    {
        _repository.Delete(parameters);
    }

    public ICustomerDO Get(IActionParameter parameter)
    {
       
    }

    public List<ICustomerDO> GetAll(ICustomerActionParameter parameter)
    {
        //Call to the Repository and it return a list of
        //Customers from database but we need to map the
        // database customer to the Customer Domain
        //Object and hence we need to new up an object
    }
}

and you might also say well change the signature of Get and GetAll so that it takes the required interface and through our IoC/DI container we will inject the actual class. And you might implement it something like this

public ICustomerDO Get(IActionParameter parameter,ICustomerDO customerDO)
{
    //perform some logic of extraction
    // and mapping and then return the object
    return customerDO;
}

 


public List<ICustomerDO> GetAll(ICustomerActionParameter parameter,List<ICustomerDO> listCustomer)
{
    //Call to the Repository and it return a list of
    //Customers from database but we need to map the
    // database customer to the Customer Domain
    //Object and hence we need to new up an object
    return listCustomer;
}

Yes this approach will work but if we need to extend this we will have to change the method signature and what if it needs more than just 2 interfaces or the depending objects have their own dependencies on other objects.(Like Logging using ILogger interface etc).

It will be ugly to pass all the interface through methods and I rather not do that. So how do i solve this problem ?

This is where the factory pattern which I mentioned in my this post comes handy.

To implment this factory and the DI I am going to use the AppServiceFactory provided by David Hayden and the code of AppServiceFactory looks like this.

public sealed class AppServiceFactory
{
    private static readonly AppServiceFactory _instance = new AppServiceFactory();
    private IWindsorContainer _container;

    public static AppServiceFactory Instance
    {
        get { return _instance; }
    }

    public T Create<T>()
    {
        return (T)_container.Resolve<T>();
    }

    private AppServiceFactory()
    {
        ConfigureServiceContainer();
    }

    private void ConfigureServiceContainer()
    {
        _container = new WindsorContainer();
        _container.Register(
            AllTypes.FromThisAssembly().BasedOn<IWindsorInstaller>()
            );
        ServiceLocator.SetLocatorProvider(() =>
           new WindsorServiceLocator(_container));
        var installers =
            ServiceLocator.Current.GetAllInstances<IWindsorInstaller>();

        foreach (var installer in installers)
        {
            installer.Install(_container, null);
        }

    }
}

I have taken his pattern as is and improvise a little bit.I first tell IoC container(Castle Windsor) to look for all classes which implement the interface IWindsorInstaller and register all the installers with the windsor container then set Service Locator to current container and get all the instances of these classes.By the virtue of the fact that these classes implement the IWindsorInstaller interface (contract) I know they have the install method and I iterate through this installers and execute the install method.

And now I can use it just like the way I would use the normal windsor container i.e.


     ICustomerDO  customerDO = AppServiceFactory.Instance.Create<ICustomerDO>();

 

If you are finding some of this stuff quite different it;s perfectly alright.May be you haven’t come across these scenarios or may be you have,and you might have a different way of solving the problem.The important thing is that we are working for the same goal i.e. Loosely coupled architecture and not newing objects directly and there is always different ways to skin a cat important thing is the effort.

In my opinion in todays day and age you should not be hard-coding classes and should not new up objects directly,it’s the IoC/DI job and let it handle it (SRP).

Service locator pattern with Windsor Castle

November 22, 2010 7 comments

I have done a couple of post on SOLID and interface driven design and I hope it gives you some insight into designing the architecture, and how you leverage good design principles and architecture to develop a loosely coupled systems.

For me it’s the architecture which is more important than the actual technology. As you can see some of my examples are in ASP.NET MVC, but it can be applied to any technology.

You can’t just use SOAP, web XML RPC and call it a loosely coupled architecture. It’s the interface design( the contract ), the separation of concern and SOLID principles which gives a  remarkable design.

One of the key thing to which I give a lot of emphasis is Inversion of Control/ Dependency Injection principle. Like other principles it is a very simple one and it’s not limited to ASP.NET MVC. If you are doing any workflow development, SOA services, enterprise level web services, integration project, middleware anything consider using this principle as well. As your system grows you will see it benefits.

If you want to know what a service locator pattern is then please refer to architecture and patterns guru Martin Fowler here. The idea is to have one registry of object and it’s dependencies and the service locator will find these services and register with the Ioc container.

One more important things is that when i talk about services it has nothing to do with SOA and web services. Consider it as a component which implements an interface and does the job. This is more of an architecture debate and I leave it up to you guys to decide what to call what, important thing is loosely coupled architecture and components.

So in order to use service locator with castle windsor you have to download it from the codeplex website. The service locator is also available for others IoC/DI like SPRING.NET, Unity, StructureMap , Autofac etc and you can get it from codeplex. Add the WindsorServiceLocator.cs file to your project.

 

Add reference to castle.core.dll and casle.windsor.dll in your project, if you’re new to Castle windsor please refer to my previous article “Getting started with Castle Windosr” in order to get up and running with it.

Now we will start thinking . . .

As we know that Castle Windsor has an interface call IWindsorInstaller and it has got just one method contract i.e Install. Which is quite fantastic as we are already seeing some SOLID principle i.e. Interface Segregation and Single Responsibility 🙂

Lets make use of this interface and create some installers. I prefer it this way as you are compartmentalized how your components(services) will get register with your IoC container

 

public class PersonInstaller : IWindsorInstaller
{
    public void Install(IWindsorContainer container, IConfigurationStore store)
    {
        container.Register(
            Component.For<IPerson>().ImplementedBy<Person>()
            );

    }
}

and a couple more for a better illustration.

public class LoanApprovalServiceInstaller : IWindsorInstaller
{
    public void Install(IWindsorContainer container, IConfigurationStore store)
    {
        container.Register(
            Component.For<ILoanApprovalService>()
                     .ImplementedBy<LoanApprovalService>()
            );

    }
}

 

public class CreditHistoryCheckInstaller : IWindsorInstaller
{
    public void Install(IWindsorContainer container, IConfigurationStore store)
    {
        container.Register(
            Component.For<ICreditHistoryCheck>()
                    .ImplementedBy<CreditHistoryCheck>()
            );

    }
}

 

This is just an example and I am sure in a real life production system each of these units(installers) will have many components registering.

Now what we are going to do is register these installers with our IoC container and ask service locator to search for these installers and execute the install method in each installer .

 

IWindsorContainer container = new WindsorContainer();
var servicelocator = new WindsorServiceLocator(container);
container.Register(
    Component.For<IWindsorInstaller>()
             .ImplementedBy<PersonInstaller>(),

    Component.For<IWindsorInstaller>()
             .ImplementedBy<CreditHistoryCheckInstaller>(),

    Component.For<IWindsorInstaller>()
             .ImplementedBy<LoanApprovalServiceInstaller>()
    );

ServiceLocator.SetLocatorProvider(() =>
                        new WindsorServiceLocator(container));

var installers =
    ServiceLocator.Current.GetAllInstances<IWindsorInstaller>();

foreach (var installer in installers)
{
    installer.Install(container,null);
}

 

In the code you will not see much advantage as it is quick prototype but imagine when your system is big and you have 100+ or 500+ interfaces and services.This is where you are thinking like an architect and thinking, how much the system will grow? how you will cope up with the changes ? and what different blocks and component you can chop and change without affecting other parts of the system ?

Suppose for above example in PersonInstaller along with Person I have a PersonRule component which implements a business rule (behaviour)and that rule changes you simply change the PersonRule component by implementing the interface and creating a new class.It’s dependencies on other components will not change as all other components use the interface and not a hard-coded class. It’s your IoC container which will decide which component will get created and not the calling code. (again single responsibility principle)

Hope this will give you some insight into the architecture and design of your current and future projects and feel free to get in touch with me, I still have so many interesting and mind boggling scenarios and ideas.

Interface & TDD Part -2: The Factory pattern

November 12, 2010 5 comments

If you guys remember back in June I did a post on interface and TDD. A very simple example in which we applied SOLID principle and separation of concern to re factor our code. I think it is more like re-factoring in our thinking, when we talk about agile we have to think like one.

If you haven’t read it yet please read it here and give me your feedback. I like the comments and came across this comment by Mr. Monk…

Monk :

So in this way how would you prevent that the fake classes get compiled for a release version?

Comment

I quickly replied to the good fella but realize will it make sense, is this really going to make things clear to him . It’s not making sense to me so how would it make sense to him. So I thought I better post it, as the crux of this matter is not in the code but in the thought process i.e. agile thinking. So lets tackle this and see what’s the problem is …

As you can see in the fake test and in the real test we are newing up the object and although it solves our purpose but it is not a good design.

  1. We have hard code the class and we have tight coupling.
  2. We are sort of breaking the single responsible principle as the invoking code (consuming code) is creating the object and using it too.

So lets see how can we can decouple the dependency and create a class which does the job of creating the right object so that we can make sure that all the test when run will invoked the fake drive method and when we run this in production then the real drive code gets executed.

And the answers to this is …(drum roll) …Factory Pattern. I know it’s a very old pattern we all have knows but never really seen in practice or makes sense…aha so we have heard that’s 50% job done as Factory means creating something and we have a problem here of creating something ;-). Lets start with a simple abstract class and we will call it BaseDriveFactory

public abstract class BaseDriveFactory
{
    public abstract IDrive CreateDrive();
}

As you can see we are creating an abstract class which creates an object of type IDrive ( Deep slow breath we are moving into the zone )…

 

Then we create 2 Factory classes for Fake and Real Drive Object …

public class FakeDriveFactory : BaseDriveFactory
{
    public override IDrive CreateDrive()
    {
        return new FakeDrive();
    }
}

and

public class RealDriveFactory : BaseDriveFactory
{
    public override IDrive CreateDrive()
    {
        return new RealDrive();
    }
}

Now you might be thinking hmm..may be I can write an if else logic to decide which object to call and depending on some flag, int or enum I will do the switch and return the right object. Well in theory it is alright but we haven’t thought agile enough and some single responsibility principles so we do some more thinking .

Now the factory are in place and we are ready to go and do the magic ..hmm may be we need a generator class which will do the creation ..good point lets do it ..

public class DriveFactoryGenerator
{
    private readonly IDrive fakeDrive;
    private readonly IDrive realDrive;

    public DriveFactoryGenerator(BaseDriveFactory factory)
    {
        fakeDrive = factory.CreateDrive();
        realDrive = factory.CreateDrive();
    }

    public void Drive(IDriveFactorySettings settings)
    {
        if (settings.ObjectFactory == "default")
        {
            realDrive.Drive();
        }
        else
        {
            fakeDrive.Drive();
        }
    }
}

Sounds interesting and looks good we have done re-factoring quite well and separation of concerns is also well implemented. If you notice I have also introduce and interface called IDriveFactorySettings. Now you must be saying what the heck why we need it, well agile thinking means anticipation and I will do a post very soon on that too but for the time being lets see what it looks like

 

public interface IDriveFactorySettings
{
    string ObjectFactory {get;set;}
}

As you can see with that interface I am just creating a contract(interface) and saying that any class which wants to manage this has to implement the interface and we are in business. I am not hardcoding it to say that it has to be from a config file or xml or registry. This is the beauty of separation of concerns and interface design is that we don’t care about the implementation.

So in order to override the behaviour all I have to do is change the IDriveFactorySettings and we get what we want. As far as the problem Mr. Monk has had all I have to do is implement a BaseTest class which all my UnitTest will inherit and have the objectfactory as anything other than “default”

So i would do something like this

public class FakeDriveFactorySettings : IDriveFactorySettings
{
    public string ObjectFactory
    {
        get { return "Fake"; }
        set { ObjectFactory = value; }
    }
}

 

and the base test class will look like

 

public class BaseTest
{
    private readonly IDriveFactorySettings _settings;
    private readonly DriveFactoryGenerator factoryGenerator;
    private readonly BaseDriveFactory factory;
    public BaseTest()
    {
        _settings = new FakeDriveFactorySettings();
        factory = new FakeDriveFactory();
        factoryGenerator = new DriveFactoryGenerator(factory);
    }

    public virtual void TestDrive()
    {
        factoryGenerator.Drive(_settings);
    }
}

and the test would look like

[TestClass]
public class DriveTest : BaseTest
{
    public override void TestDrive()
    {
        base.TestDrive(); // calling the fake one
                          //as it already set for
                          //the entire test
                         
    }
}

The final class diagram..
Class Diagram

that’s it from me and guys keep your comments coming.I would like to know your perspective into the whole SOLID way of thinking and as well interesting problems you guys face in your daily coding 🙂

Dependency Injection in WCF Service

October 11, 2010 20 comments

In this post I will show you how to use dependency injection in a typical WCF Service and the architecture of the solution is a standard layered approach i.e. Service calls the business logic layer and business logic layer calls the data access layer etc.

In order to use Dependency Injection in WCF we are going to use the WcfFacility provided by Castle Windsor. This is another one of those good extension points in Castle Windsor which implements the IFacility interface and this is the class that does all the underlining pluming of WCF Service host.

In order to get started with WCF facility lets download it from the castle project from github website which is at http://github.com/castleproject/Castle.Facilities.Wcf.

Wcf facility download from github

Build the project which will build the binary, and we will need all the three binaries i.e.

  • Castle.Core.dll
  • Castle.Windsor.dll
  • Castle.Facilities.WcfIntegration.dll

Build binaries

I had a bit of gotchas here as my project had reference to the previous version of Castle.Core and Castle.Windsor i.e. 2.5.0 and the newly build Castle.Facilities.WcfIntegration was of version 2.5.1 so make sure you copy all the three assemblies to your project.

Now my favourite part that is File > New > WCF Service application

WCF Project

Lets get down to writing some code. First we will create the data access layer using a repository pattern, this is just an illustration of an end-to-end dependency injection.

ICustomerRepository.cs

public interface ICustomerRepository
{
    Customer GetById(int Id);
}

Customer.cs

public class Customer

     public int Id { get; set; } 
     public string FirstName { get; set; } 
     public string LastName { get; set; } 
     public int Age { get; set; }
}

CustomerRepository.cs

public class CustomerRepository : ICustomerRepository 
{
    public Customer GetById(int Id)
    {
         return new Customer {
                    Id = 5,
                    FirstName = "Joe",
                    LastName = "Blogg",
                    Age = 45
         };
    }
}

Moving one layer up lets build the business logic layer in which we will also use constructor injection to inject the dependency, also for easy illustration I am going to create the business logic layer and service layer as simple pass through and you will see that they don’t do much but in real life project it would be much more sophisticated and complex too.

ICustomerBl.cs

public interface ICustomerBl
{
    Customer GetById(int Id);
}

CustomerBl.cs

public class CustomerBl : ICustomerBl
{
    private readonly ICustomerRepository repository;

    public CustomerBl(ICustomerRepository repository)
    {
        this.repository = repository;
    }

    public Customer GetById(int Id)
    {
        return repository.GetById(Id);
    }
}

We are almost there, lets finish the services layer too.

public interface ICustomerService
{
    [OperationContract]
    Customer GetById(int Id);
}

CustomerService.cs

public class CustomerService : ICustomerService
{
    private readonly ICustomerBl customerBl;

    public CustomerService(ICustomerBl customerBl)
    {
        this.customerBl = customerBl;
    }

    public Customer GetById(int Id)
    {
        return customerBl.GetById(Id);
    }
}

And this is how my end project structure looks like.

Project structure

Now with all the coding done lets see how we will wire up rest of the stuff. First we need to change the declaration in service file and in order to do that, just right-click on the CustomerService.svc and open with XML (Text) Editor and add the following code.

CustomerService.svc

<%@ ServiceHost Language="C#" Debug="true" 
    Service="WindsorWcfIntegration.CustomerService" 
    Factory="Castle.Facilities.WcfIntegration.DefaultServiceHostFactory, Castle.Facilities.WcfIntegration" 
    CodeBehind="CustomerService.svc.cs" %>

With the above declaration we are saying that when ever the customer service is requested the DefaultServiceHostFactory will take care of how the service is created and instantiated. Let’s wire this up with the WcfFacility and since it has to happen at some startup process so we will do that in Global.asax file of the WCF Service project.

Global.asax.cs

public class Global : System.Web.HttpApplication
{
    public WindsorContainer Container { get; protected set; }

    protected void Application_Start(object sender, EventArgs e)
    {
        Container = new WindsorContainer();
        Container.AddFacility<WcfFacility>();
        Container.Register(
            Component.For<ICustomerRepository>().ImplementedBy<CustomerRepository>(),
            Component.For<ICustomerBl>().ImplementedBy<CustomerBl>(),
            Component.For<ICustomerService>().ImplementedBy<CustomerService>()
            );
    }
}

As you can see in the above code we are instantiating a new instance of WindsorContainer and adding the WcfFacility and then we go ahead & register all the interfaces and its concrete implementation and at the end we register the service contract ( interface) and the implementing service class.

Now let’s do a quick test by running the wcf test client and as you can see the service comes out without any errors so it’s all good.

WCF Test Client

And when we invoke the GetById method we get our desired result.

Test results

Hope this serve as a quick start tutorial into DI and you will be able to use Dependency Injection in your WCF project.