4

I have been developing a new MVVM framework here.

It has some interesting concepts, but I'd like to support multiple IoC containers. Right now I'm supporting just MEF, because it comes with .Net 4.0.

What are some of the more common IoC/DI frameworks I should look into supporting from the start? I'm thinking maybe 3 or so.

Castle Windsor? Ninject?

EDIT:

Just to clarify, I'm asking which IoC/DI frameworks are commonly used today. I was hoping to also learn of some of the new hotness that's out there and I've not heard of yet.

jonathanpeppers
  • 26,115
  • 21
  • 99
  • 182
  • 1
    How do you support them? Have you looked at CommonServiceLocator? Or my http://docs.griffinframework.net/specification/ – jgauffin Aug 11 '11 at 12:12
  • I haven't worked out the *how* yet. I was considering abstracting that out myself, but I'll check out your link. – jonathanpeppers Aug 11 '11 at 12:15
  • Look at the way ASP.NET MVC uses a DI container: it does not. It has a DefaultControllerFactory implementation that works with Activator.CreateInstance and it is very easy to plug in your own controller factory that works with your own DI container. – Steven Aug 11 '11 at 14:43
  • Yes, that's what I want to do. I want to provide a MEFFactory, WindsorFactory, NinjectFactory, etc. What are some commonly used containers I can support out of the box? (This is what my question is asking) – jonathanpeppers Aug 11 '11 at 15:12

3 Answers3

12

A library or framework should not use a DI Container - only applications should use containers.

Libraries and frameworks should be designed so that they are friendly to any sort of DI, whether or not the user wants to use a container or Poor Man's DI.

Assume that the user will be using Poor Man's DI and you will automatically be container agnostic.

Community
  • 1
  • 1
Mark Seemann
  • 225,310
  • 48
  • 427
  • 736
  • There is a View <-> ViewModel hookup mechanism that uses DI in my framework. This is the reason for using a container. I don't want the user of my framework to have be manually setting DataContext on his Views. I see your point though. – jonathanpeppers Aug 11 '11 at 12:33
  • I want to support containers similar to how Caliburn does: http://caliburn.codeplex.com – jonathanpeppers Aug 11 '11 at 12:35
  • 2
    Move your DI logic out of your library and encapsulate it into an interface that sets the datacontexts for you. Then the application developer used there DI container of choice to implement your interface – cordialgerm Aug 11 '11 at 12:36
  • Yes that's exactly the idea. Then I would have separate libraries for supporting MEF, Castle Windsor, etc. My question asks *which* of these libraries to support. – jonathanpeppers Aug 11 '11 at 12:38
  • Prism offers the same kind of IoC/DI that he wants to implement, so library/frameworks may very well use them as long as they offer to switch to another one easily if it doesn't suit the user. – Louis Kottmann Aug 11 '11 at 16:05
4

Unity and Castle Windsor should be a must in my opinion, especially Unity since it's used in Prism and it is part of the Enterprise Library (for portability). And Castle windsor for its easy of use (for a broader community)

Louis Kottmann
  • 16,268
  • 4
  • 64
  • 88
0

An alternative would be to provide a simple IoC Container just like Mvvm Light does.

Matthieu
  • 4,605
  • 4
  • 40
  • 60