ASP.Net MVC Controller injection

Question

I am looking for suggestions on good ways to design a new ASP.NET Mvc project. It is of medium size and is relatively simple in structure. I had initially used Spring.Net to wire my service objects into the correct constructors but now management has told me that Spring.Net or any other IOC container is not to be use in our environment.

I am having a bit of trouble figuring out a good way to set this up without DI. I would like to be able to assign service implementations to controllers in a way that allows for a low amount of coupling between controllers and services and to limit, as much as possible, the dependably of controllers on individual service implementations. I guess my question boils down to that fact that I am unsure of where I should manually wire up my application in the MVC model.

Any suggestions?

Answer 1

Since you are using ASP.NET MVC 3 you could write a custom dependency resolver. You will of course still design your controllers taking interfaces in their constructors in order to weaken the coupling between the layers. And then in the custom dependency resolver, in order to satisfy the ridiculous requirement that was imposed to you, you will have to manually say that when you have an ISomeService you return an instance of SomeServiceImpl. You know, the kind of things that object containers and DI frameworks already do for you. So you will basically have to reinvent some wheels. By the way Ayende blogged about how you could build a custom IoC container in 15 lines of code but of course that's not a reason that you should ever do anything like this.

People imposing such requirements should face a trial and be sentenced to never ever have to approach an application design. Imposing such requirement illustrates some total lack of knowledge about good practices in designing applications. Those people should be advised before they bring further damage to the company.

So simply explain those people that by reinventing wheels there are 2 mistakes:

• you will waste a lot of time for something that was already done by someone else
• you will make errors as you will not take into considerations all the edge cases that were taken into account by someone else designing a reusable DI framework.

At the end of the day you will ship your application late on schedule (as you would have wasted time to write plumbing code) and even worse you will ship an application that will contain potential bugs.

Conclusion: expensive and buggy product. Your management must have really has lost its mind :-)

Conclusion2: use an existing DI framework. Management won't even notice as they don't seem to understand the technical aspects of an application by imposing such requirements.