Using non-Unity/MEF Dependency Injection

Topics: Prism v4 - WPF 4
Jun 23, 2014 at 8:49 PM
I'm starting a new WPF application and planning on using Prism 5. I've seen plenty of discussions regarding Unity vs. MEF, however I was wondering about using a wholly different DI container like LightInject.

I know that using a different DI container with Prism is possible, but has anyone actually done it? I know it involves a custom implementation of IServiceLocator inheriting from ServiceLocatorImplBase, but to before going down that road I'm trying to determine if I'm opening a can of worms. Perhaps its best to conform to Unity or MEF.

What is the level of effort, and are there any examples/posts regarding all the steps involved in using a non-Unity/MEF DI container?
Jun 25, 2014 at 9:45 AM

I am new to Prism and Composite UI patter as well and first time I need to study that approach because a customer need to be able to design the layout of the UI.
So first thing I do is running the Getting started sample in order to get the basics and usually I like to keep tight to what the sample use , this first for simplicity understanding and maybe also to be quite sure of the proven implementation.

Prism seems to be a big complex package, so why adding a new complexity by using an other Container type as it is already providing it ?

Jun 28, 2014 at 3:16 AM

Prism can be used with other container beside the ones that are supported as out of the box, but it requires to perform certain tasks to “adapt” the container to Prism. To start, you will need to:

· Create a custom implementation of IServiceLocator like you mentioned above.

· Create a custom implementation of a bootstrapper.

· Register all the services and types provided by Prism in the new container.

However, if the container you want to use is well known by the community, you might be able to find a post or project describing an approach to use it .

A good example of what changes you might need to adapt the container to Prism can be found in Prism’s source code. The project Prism.Desktop contains most of the main functionality used in Prism but does not depend on any container. The extensions required to use MEF and Unity are located in the corresponding Prism.MefExtensions and Prism.UnityExtensions projects. There it can also be seen that the amount of effort required to adapt the container depends on the container itself: Unity just requires a couple of classes while MEF needs to create subclasses of almost any Prism service to be able to export them.

In my opinion, using a different container might be worth the effort if the container provides a functionality that is not available in MEF or Unity and that you need to use in your project. If not, then it might be simpler to use the containers that are supported as out of the box.

Ezequiel Jadib