In this blog post I will explain how to inject your dependencies into your controllers in a MVC 3 application with Castle Windsor.
First of all you need to create a WindsorInstaller. This class is responsible for the configuration of your IoC container.
In the above class the first line registers all your controllers with lifestyle configured to Transient. Depending on the lifestyle you choose Windsor will clean all resources. Other lifestyles are Singleton, Pooled, PerWebRequest, PerThread. That’s why it is strongly recommended to implement IDisposable on your classes so Windsor can handle all your resources automatically.
You also need to implement a WindsorControllerFactory. This will attach the System.Web.Mvc.DefaultControllerFactory to Windsor.
Last but not least you have to bootstrap your container. This is done in your Application_Start() method in the global.asax file.
With this things setup all the dependencies you registered in your WindsorInstaller will be automatically injected to your controllers. Below I have added an example controller implementation to show you how to use the dependencyInjection.
To keep track on your resources you should implement IDisposable on your repositories so resources will be released automatically. In the example I use Entity Framework Code First. Because I implemented the Dispose method, also my connection to my database will be released without the need to think about it everywhere in my code.
I hope you found this blog post usable.
You have disabled cookies. To leave me a comment please allow cookies at functionality level.
The current project I'm doing is a CQRS based project, using the ncqrs framework. Today I came to a phase I needed some mocking done for some of my domain services. I choose FakeItEasy to handle this for me. So I started by just adding a reference to my DomainScenario project using a Nuget package.
For some of my complexer scenario's I ran into some issues which took me about about 45 minutes to fix one of my tests. For fixing all other failing tests I had to do the same trick.
Before I explai…
While I was trying to apply DDD in combination with CQRS I learned myself some good lessons.
I was trying to apply this in an agile approach, using the project method SCRUM. I started the project by translating all use-cases to smaller user stories. Based on this user stories I defined a first sprint.
In the first sprint I didn't had or make a design for the complete domain. So I wasn't completely sure if I made the right decision for the 'aggregate root / bounded contexts' needed for the firs…
In this blog post I work out some of the notes I made in Greg Young’s DDD/CQRS course in Krakow Poland.
In Domain Driven Design there are some important things to think about. In DDD we make a difference in the following components.
An Aggregate root is a set of multiple things that belong to each other. The aggregate should have a name that describes the whole.
To come to a domain driven design you should take the following steps: