Consider creating a ContainerProvider


I noticed there's an IPrismContainer interface which is not used.
I would like to suggest that a ContainerProvider be created so that a concrete Dependency Injection provider can be specified in a configuration file. For example, the interface and base classes (if needed) would live in Prism.Container, and any concrete provider implementations would live in external assemblies such as: Prism.Container.Unity etc. Obviously, this would enabled the benefit of being able to swap out or change the provider via a configuration file change. And, it prevents the need of hard-coding a reference to IUnityContainer.
Feel free to change the nomenclature though, if you feel "Container" is too ambiguous. However, I do not recommend using anything too specific in the name, such as "DependencyInjection", or "InversionOfControl", or even their well know abbreviations.
Closed May 8, 2008 at 8:41 AM by gblock


ejstembler wrote Mar 24, 2008 at 8:42 AM

Now that I think about it, it would probably be pretty difficult to create a DI provider since some DI engines use declarative artifacts such as attributes to mark properties for injection. Requiring knowledge of the concrete provider in the consuming code kind of defeats the purpose of a provider.

Feel free to delete this work item...

DenisVuyka wrote Apr 1, 2008 at 11:34 AM

I don't think this will be pretty difficult actually. I've used pure Unity for creating something like that here in my blog post

Injecting Xaml with Unity Application Block using Markup Extensions

Good container and a set of markup extensions can save you time a lot

gblock wrote Apr 1, 2008 at 11:03 PM

ejstembler IPrismContainer is a wrapper to a specific DI implementation. OOTB if you are using DI you can handle the concrete implementation being supplied through config and not code. We did this in our initial spikes. Today you can go and move the UnityPrismContainer registration to config if you so desire.

gblock wrote Apr 1, 2008 at 11:05 PM

@estembler actually IPrismContainer is NOT meant to be the container you use in your application code. It is purely an abstraction to the container that can be used by core services such as the future ModuleLoaderService. The reasoning for this is because containers have different semantics, and if you chose a container, you probably also chose those semantics. This is why in our RI we don't show using IPrismContainer. We will be using it shortly though as in the next drop the RegionManagerService relies on IOC to resolve the region handler class.