There is an unsaved comment in progress. You will lose your changes if you continue. Are you sure you want to reopen the work item?

1

Closed

Consider creating a ContainerProvider

description

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.

file attachments

comments

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.

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.

@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.