Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I was going to refactor my ASP.NET MVC application and inject some IoC. Last time I was using IoC, Unity was all the rage, but I hated it. It was difficult to setup and had very nondescript errors.

Does anyone have any suggestion or preferences?

share|improve this question

closed as primarily opinion-based by gnat, Kilian Foth, Dan Pichelman, MichaelT, BЈовић Jul 25 '13 at 6:17

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

    
Update: I've added a few missing details Here are some dependency injection libraries you can try: 1. Ninject 2. Autofac 3. Structure Map 4. Unity - which I actually kind of like, maybe you should ask about the problems you had with it. Also MVC3 has made using IOC containers alot easier with the new interface [IDependencyResolver](cnug.co.in/blogs/shijuv/archive/2011/01/21/… –  Daniel Little Nov 16 '11 at 23:38
    
What exactly did you find hard about Unity and what are nondescript errors? –  Daniel Little Nov 17 '11 at 1:23
    
It has been a while since I used Unity, so I apologize that my complaints about it are vague. But as I recall, setting and configuring it was a pain, and the error messages didn't seem to point me in the right direction. I may give Unity another try. –  SteveB Nov 17 '11 at 17:50
add comment

3 Answers

up vote 5 down vote accepted

Personally, I really like Ninject.

It's simple, yet powerful and allows you to achieve the "easy" parts of DI easily, whilst still giving plenty of scope for more advanced DI scenarios.

It's also fairly lightweight and easy to set-up within your project/application.

This is especially true for ASP.NET MVC applications if you're using NuGet, as there is a Nuget package for the Ninject assembly itself (Ninject), along with another Nuget package which tightly integrates Ninject with ASP.NET MVC 3 (Ninject.MVC3) (which uses such things as WebActivator to allow assemblies to execute start-up code etc.)

There's a few blog posts out there to help get started with all this, too.

share|improve this answer
    
Thanks for all your comments everyone. I think I'm going to try ninject and I may even give Unity another whirl. –  SteveB Nov 17 '11 at 17:47
add comment

You don't 'inject' IoC into anything. Inversion of Control, or more specifically Dependency Injection, is a technique where you inject services into consumers - preferably via Constructor Injection.

In ASP.NET, all you need in order to do that is a custom IControllerFactory. You can, however, implement that IControllerFactory with a DI Container to make things a little easier. Here's a list of various DI Containers for .NET.

share|improve this answer
add comment

I'm surprised nobody mentioned Spring.NET ? It's been available for a long time now, and it has the advantage of being based on the Java Spring Framework (based on the IOC "idea", and separation of packages/namespaces, there is no Java in Spring.NET) as for its maturity and ease of use. Also, if you happen to use both languages in your professional environment, it's great to have some common tools/API's between both.

It integrates pretty well with NHibernate, provides AOP programming tools and you can easily make it work with ASP.NET MVC 2/3.

As for Unity, I've never used it so I can't say.

I may just add that there also is the LinFu Framework, which is a bit more lightweight than Spring. There is a great tutorial on how to integrate LinFu with ASP.NET MVC courtesy from Thomas Weller. I also used LinFu for one of my personal projects and it was really easy to work with.

share|improve this answer
    
Being based on Java is not at all an advantage when it comes to DI Containers, because Java has inferior Reflection capabilities compared to .NET. This artificially constrains Spring.NET. –  Mark Seemann Nov 17 '11 at 7:13
    
@MarkSeemann What? There is no piece of Java code in Spring.NET, it is a full .NET managed library. With that remark do you imply that Spring.NET developers used reflection the wrong way, or did they copy/paste their code from the Java source code ? –  Jalayn Nov 17 '11 at 7:19
    
Spring.NET's architecture, API and feature set is based on (Java) Spring. There's lots of things that you can do with a DI Container in .NET that Spring.NET can't do because it has to 'follow' the Java library. –  Mark Seemann Nov 17 '11 at 7:28
    
Ah OK, thanks for the information, I'm starting to see how it can be a constraint. I won't change my comment because that will make these comments look strange :-) But can you agree that it may be a disadvantage performance-wise, but an advantage at least for configuration part being similar for both platforms ? –  Jalayn Nov 17 '11 at 7:37
    
As I see it, the main advantage of Spring.NET is that it's easier for a Java developer coming to .NET to adopt it. –  Mark Seemann Nov 17 '11 at 8:54
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.