web-dev-qa-db-fra.com

Quel conteneur IoC est le meilleur avec Prism.

Je suis au début d'une nouvelle Prism.Forms projet et je me demandais lequel des divers IoCconteneurs (Autofac, Dryloc, Ninject ou Unity) serait préférable d'aller de l'avant.

Je ne sais pas si c'est vrai, mais j'ai lu quelque part que Unity n'est plus en développement actif et puisque cela et MEF sont les seuls IoCconteneurs j'ai jamais utilisé, je ne sais pas si c'est la voie à suivre.

En attendant, je connais peu ou rien sur Autofac, Dryloc ou Ninject.

Veuillez être objectif dans tout conseil, en fournissant des raisons pour lesquelles vous pensez que l'un est meilleur que les autres plutôt que simplement "j'utilise xxx"; Je voudrais prendre une décision éclairée.

xamarin.formsinversion-of-controlioc-containerprism-6
21
Martin Robins

Le mieux que je puisse faire est de présenter les faits tels qu'ils sont actuellement.

DryIoc est le conteneur que j'utilise et que je recommande le plus. Il est en développement actif, il est très rapide et fonctionne bien avec la version actuelle de Prism. Il est également important que lorsque j'ai eu des questions ou des problèmes, le responsable ait été très rapide pour résoudre le problème ou répondre à la question que j'avais. C'est pour toutes ces raisons que je continue de recommander le conteneur. Contrairement à Unity, l'API a tendance à être très stable et je n'ai pas encore eu de problème avec la mise à jour de DryIoc au-delà de ce qu'une version particulière de Prism visait.

nity est le conteneur le plus populaire car il s'agit du conteneur que Brian utilise depuis des années et du premier (et depuis longtemps uniquement) conteneur disponible dans les modèles. Il avait passé un certain temps sans être entretenu, mais le projet a un nouveau mainteneur. Il convient de noter qu'il y a eu un certain nombre de changements de rupture dans Unity 5, ce qui rend la mise à niveau vers Unity 5 avec Prism 6.3 impossible. Prism a cependant mis à jour vers Unity 5 sur toutes les plates-formes de Prism 7. Unity est également dans la moyenne en ce qui concerne ses performances de référence. Pour ceux qui passent à Prism 7 à partir de Prism 6.X, notez que vous devez désinstaller toutes les références à Unity ou au Common Service Locator, puis mettre à jour Prism.Unity.Forms qui cible désormais le package Unity.Container NuGet au lieu du package Unity NuGet. Vous devez également prendre en compte que le ciblage d'une version plus récente de Unity que celle contre laquelle Prism est construit peut interrompre votre application car Unity a introduit un certain nombre de changements de rupture sans explication ni documentation de Minor Patch à Minor Patch.

Autofac, bien qu'il soit populaire, est un conteneur que je déconseille généralement d'utiliser. Les gens semblent très confus par l'API. Dans Prism 6.3, il souffre d'une implémentation vraiment médiocre. Prism 7 introduit plusieurs changements de rupture et a résolu de nombreux problèmes liés à l'enregistrement en vous fournissant le ContainerBuilder utilisé par PrismApplication. Parce que la communauté Autofac insiste pour rendre le conteneur non modifiable, ce sera toujours un conteneur que je déconseille d'utiliser. Bien que cela fonctionne pour les applications de base, il vous empêchera d'utiliser des fonctionnalités Prism plus avancées telles que la modularité. REMARQUE: suite à la sortie de Prism 7.1, l'équipe de Prism a décidé d'interrompre toute prise en charge supplémentaire du conteneur Autofac. L'équipe de Prism croit que si un conteneur ne peut pas prendre en charge toutes les caractéristiques et fonctionnalités que Prism offre, il ne devrait pas être un conteneur officiellement pris en charge.

Ninject (obsolète) est ok. C'est certainement le conteneur le moins utilisé, et d'après les références des différents conteneurs, c'est aussi le plus lent. Prism 6.3 a utilisé Portable.Ninject qui semble être un projet mort. Prism 7.0 a tenté d'utiliser le projet officiel Ninject qui ciblait initialement NetStandard2.0. La prise en charge du conteneur a ensuite été complètement retirée en raison d'incompatibilités fondamentales entre le conteneur Ninject et Xamarin Android et Xamarin iOS.

DryIoc est le conteneur que j'utilise et que je recommande le plus. Il est en développement actif, il est très rapide et fonctionne bien avec la version actuelle de Prism. Il est également important que lorsque j'ai eu des questions ou des problèmes, le responsable ait été très rapide pour résoudre le problème ou répondre à la question que j'avais. C'est pour toutes ces raisons que je continue de recommander le conteneur. Contrairement à Unity, l'API a tendance à être très stable et je n'ai pas encore eu de problème avec la mise à jour de DryIoc au-delà de ce qu'une version particulière de Prism visait.

MISE À JOUR

Il convient de noter qu'à partir de l'aperçu 5 de Prism 7, nous avons résumé les conteneurs. Cela facilitera en fin de compte beaucoup plus facilement le conteneur de votre choix, car l'API est exactement la même en ce qui concerne la façon d'enregistrer vos services et vos vues. Vous aurez toujours accès au conteneur et dans le cas d'Autofac, le ContainerBuilder via des méthodes d'extension, afin que vous puissiez effectuer des enregistrements plus complexes.

// 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>();
}

Il est également important de se rappeler que si les abstractions IoC de Prism ont facilité la mise en place d'une API plus unifiée, cela ne vous enlève pas la possibilité d'interagir directement avec le conteneur sous-jacent. Pour accéder au conteneur sous-jacent, il vous suffit d'appeler la méthode d'extension GetContainer et vous pourrez effectuer toute action plus complexe qui n'est pas directement prise en charge par les abstractions IoC de Prism.

MISE À JOUR 2

Prism 7.2 a introduit quelques changements d'API autour des abstractions IoC. Dans l'ensemble, ces changements ne devraient pas affecter la plupart des utilisateurs. Cependant, vous pouvez rencontrer des incompatibilités binaires si vous utilisez d'autres bibliothèques qui référencent Prism comme Prism.Plugin.Popups qui n'a pas été construit contre 7.2.

Les modifications de l'IoC incluent:

  • Une API Fluent
  • Une capacité à vérifier si un service est enregistré
  • Ajout de méthodes pour permettre aux services transitoires et singleton d'être des services nommés
  • Ajout de la possibilité de résoudre un service avec des instances spécifiées.
50
Dan S.