6

My team plan to start a new project this June. This application tend to used by 2,000 concurrent users. Now we are discussing about technical decision - what IoC container we will use in our project. All members in my team don't have experience with IoC, some of us read and know what it is though. Our requirements are:

  1. Performance - Our management state that IoC may slow down the application and they expect that IoC container we use will not degrade the performance. They also expect the IoC container to have a good performance for little or large or resolver process.
  2. Feature sets - I an my coworkers expect it to has rich feature sets. I don't know at this time what feature we gonna use but I have experience that some component can start easy but can't do something more advance.
  3. Documents or books - I plan to study the IoC we selected by reading from online documents or books.
  4. Work with ASP.NET MVC 4
Anonymous
  • 9,366
  • 22
  • 83
  • 133
  • 1
    Please check http://stackoverflow.com/questions/1140730/net-ioc-container-comparisons. Also while selecting a IoC container make sure that it can be used without leaving too much footprint all around the code. – Chandermani Mar 26 '12 at 05:32
  • @Chandermani Thank for the link. I read that question but it asked nearly three years ago. I am not sure, is it dated or not? – Anonymous Mar 26 '12 at 15:45
  • 2
    See http://www.iocbattle.com/ and the git test harness and you can yourself benchmark with updated IoC containers. Also read this thread from SO. This guys answered the best http://stackoverflow.com/questions/5315562/di-ioc-container-performance-benchmark-comparison – Chandermani Mar 26 '12 at 17:00

1 Answers1

7

I've used StructureMap, Autofac and Ninject. They are all very good.

I'd recommend using the CommonServiceLocator [http://commonservicelocator.codeplex.com] as part of your implementation. That way it is easy to change your mind later.

I personally like Autofac the best. It has a good balance of features and simplicity.

  • Supports Autowiring and assembly scanning
  • Lifetime Scoping (Such as Singleton or HttpRequest)
  • Easy to register an implementation to multiple request types
  • Supports Named or Keyed (named by Enum) registration
  • It's fast

http://code.google.com/p/autofac/wiki/MvcIntegration http://nuget.org/packages/Autofac.CommonServiceLocator-unofficial

Jeremy Bell
  • 698
  • 5
  • 9
  • Since whoever down-voted you didn't have the courtesy to say why, I'm going to guess it's because the Common Service Locator is considered an anti-pattern around here, aka bad practice. – Chris Moschini Sep 10 '12 at 19:11
  • I fail to see why the CommonServiceLocator is a bad idea given that the question asked was about IoC containers in an MVC project. The DependencyResolver.SetResolver method even accepts the CommonServiceLocator as one of the overloaded methods. – Jeremy Bell Sep 15 '12 at 18:21
  • It's a bad practice because it takes whatever container you use down to the lowest common denominator. You lose a lot of the special functionality that the container provides. – Shane Courtrille Nov 15 '13 at 21:06