Which IoC container is better with Prism.Forms

I am in the start of a new Prism.Forms project and I was wondering which of the various IoC containers (Autofac, Dryloc, Ninject or Unity) would be best to move forward with.

I do not know if this is true, but I read somewhere that Unity is no longer under active development and since this and MEF are the only IoC containers I have ever used I am unsure as to whether it is the way to go.

Meanwhile, I know little or nothing about Autofac, Dryloc or Ninject.

Please be objective in any advise, providing reasons why you feel one is better than the others rather than simply "I use xxx"; I would like to make an informed decision.

The best I can do is to layout the facts as they currently stand.

DryIoc is the container I use and recommend the most. It's under active development, it's very fast, and works well with the current release of Prism. Also important is that when I have had questions or issues the maintainer has been very quick to address the issue or answer the question I had. It's for all of these reasons I continue to recommend the container. Unlike Unity the API tends to be very stable and I have not yet had an issue with updating DryIoc beyond what a particular release of Prism was targeting.

Unity is the most popular container due to it being the container that Brian has used for years and it being the first (and for a long time only) container available in the Templates. It had gone quite some time without being maintained, however the project does have a new maintainer. It's worth noting that there were a number of breaking changes in Unity 5 which makes upgrading to Unity 5 with Prism 6.3 an impossibility. Prism has however updated to Unity 5 across all platforms in Prism 7. Unity is also about average with regards to it's benchmark performance. For those upgrade to Prism 7 from Prism 6.X note that you should uninstall any references to Unity or the Common Service Locator and then update Prism.Unity.Forms which now targets the Unity.Container NuGet package instead of the Unity NuGet package. You should also beware that targeting a newer version of Unity than what Prism is built against may break your application as Unity has introduced a number of breaking changes without explanation or documentation from Minor Patch to Minor Patch.

Autofac, despite being popular, is a container I generally would advise against using. People seem to be very confused by the API. In Prism 6.3 it suffers for a really poor implementation. Prism 7 introduces several breaking changes and has resolved a lot of the issues around registration with providing you the ContainerBuilder that is used by PrismApplication. Because the Autofac community is insistent on making the container non-mutable, it will always be a container I recommend against using. While it will work for basic apps, it will prevent you from using more advanced Prism features like Modularity. NOTE: That following the release of Prism 7.1 the Prism team has decided to discontinue all further support for the Autofac Container. It is the belief of the Prism team that if a Container cannot support all of the features and functionality that Prism offers then it should not be an officially supported container.

Ninject (DEPRECATED) is ok. It's certainly the least utilized container, and from benchmarks of the various containers it's also the slowest. Prism 6.3 utilized Portable.Ninject which appears to be a dead project. Prism 7.0 attempted to utilize the official Ninject project which initially was targeting NetStandard2.0. Support for the container was later pulled completely due to fundamental incompatibilities between the Ninject Container and Xamarin Android and Xamarin iOS.

UPDATE

Well worth noting is that starting with Preview 5 of Prism 7 we have abstracted the containers. This will ultimately make it far easier to switch between the container of your choosing as the API is exactly the same with regards to how to register your services and Views. You will still have access to the Container and in the case of Autofac the ContainerBuilder through extension methods, so that you can accomplish more complex registrations.

// Prism 6.X way of Registering Services
protected override void RegisterTypes()
{
    // Container Specific Registrations

    // Autofac
    Builder.RegisterType<DebugLogger>().As<ILoggerFacade>().SingleInstance();

    // DryIoc
    Container.Register<ILoggerFacade, DebugLogger>(reuse: Reuse.Singleton,
                                                   ifAlreadyRegistered: IfAlreadyRegistered.Replace);

    // Ninject
    Container.Bind<ILoggerFacade>().To<DebugLogger>().InSingletonScope();

    // Unity
    Container.RegisterType<ILoggerFacade, MCAnalyticsLogger>(new ContainerControlledLifetimeManager());
}

// Unified API in Prism 7
protected override void RegisterTypes(IContainerRegistry containerRegistry)
{
    containerRegistry.RegisterSingleton<ILoggerFacade, DebugLogger>();
}

It is also important to remember that while Prism's IoC abstractions have made it easier to have a more unified API, this does not remove your ability to interact directly with the underlying Container. To access the underlying container you simply need to call the GetContainer extension method and you will be able to perform any more complex action that is not directly supported by Prism's IoC abstractions.

UPDATE 2

Prism 7.2 has introduced some API changes around the IoC Abstractions. Notably by and large these changes should not affect most users. However you may experience binary incompatibilities if using other libraries that reference Prism such as the Prism.Plugin.Popups that wasn't built against 7.2.

The IoC changes include:

A Fluent API
An ability to check if a service is registered
Added methods to allow both transient and singleton services to be Named Services
Added ability to resolve a service with specified instances.

来源：https://stackoverflow.com/questions/43664455/which-ioc-container-is-better-with-prism-forms

标签

xamarin.forms

inversion-of-control

ioc-container

prism-6