Je viens de commencer à étudier la DI (je travaille sur WPF/Silverlight mais j'ai l'intention de passer à ASP.NET). Après avoir lu quelques articles sur l'ID sur Internet, il y a deux Frameworks qui m'intéressent, MEF et Unity. Je veux savoir quelle est la différence réelle entre eux et lequel est le plus approprié.
Réponses
Trop de publicités?La principale différence est qu'avec unity, vous enregistrez explicitement chaque classe que vous voulez utiliser dans la composition :
var container = new UnityContainer();
container.RegisterType<IFoo,Foo>();
container.RegisterType<IBar,Bar>();
...
var program = container.Resolve<Program>();
program.Run();
En revanche, dans MEF, vous marquez les classes avec des attributs au lieu de les enregistrer ailleurs :
[Export(typeof(IFoo))]
public Foo
{
...
}
À première vue, il s'agit d'une différence syntaxique mineure, mais elle est en fait plus importante que cela. Le MEF est conçu pour permettre la découverte dynamique de pièces. Par exemple, avec un DirectoryCatalog
vous pouvez concevoir votre application de telle sorte que vous puissiez l'étendre en déposant simplement de nouvelles DLL dans le dossier de l'application.
Dans cet exemple, le MEF trouvera et instanciera toutes les classes ayant un nom de classe [Export(typeof(IPlugin))]
dans le répertoire donné et transmet ces instances à la fonction Program
constructeur :
[Export]
public class Program
{
private readonly IEnumerable<IPlugin> plugins;
[ImportingConstructor]
public Program(
[ImportMany(typeof(IPlugin))] IEnumerable<IPlugin> plugins)
{
this.plugins = plugins;
}
public void Run()
{
// ...
}
}
Point d'entrée :
public static void Main()
{
using (var catalog = new DirectoryCatalog(".","*"))
using (var container = new CompositionContainer(catalog))
{
var program = container.GetExportedValue<Program>();
program.Run();
}
}
Pour s'adapter à de tels scénarios de composition dynamique, le MEF dispose d'un concept de "composition stable", ce qui signifie que lorsqu'il rencontre une dépendance manquante quelque part, il marque simplement la partie comme indisponible et poursuit quand même la composition.
Une composition stable peut être très utile mais cela permet aussi il est très difficile de déboguer une composition qui a échoué . Donc, si vous n'avez pas besoin d'une découverte dynamique des pièces et d'une "composition stable", j'utiliserais un conteneur DI ordinaire au lieu du MEF. Contrairement à MEF, les conteneurs DI ordinaires vous donneront des messages d'erreur clairs lorsqu'une dépendance est manquante.
Il est également possible d'obtenir le meilleur des deux mondes en utilisant un conteneur DI qui s'intègre au MEF, tel que Autofac . Utilisez Autofac pour composer l'application de base, et MEF pour les parties qui doivent être dynamiquement extensibles.
Il existe de nombreuses possibilités de faire du bricolage. Tout d'abord, vous devez comprendre que l'ID n'est pas une question d'outils, mais plutôt de modèles et de principes. Vous pouvez très bien utiliser l'ID sans outil. Si vous faites cela, nous l'appelons DI du pauvre .
Cependant, cela dit, Il existe de nombreux conteneurs DI pour .NET. . L'unité est l'une d'entre elles.
Le MEF ressemble beaucoup à un conteneur DI, mais il résout actuellement un problème différent, celui de l'extensibilité. Au lieu de configurer les composants de manière externe (ce que font tous les conteneurs DI), il utilise un système de gestion des attributs. mécanisme de découverte .
J'ai présenté une comparaison très détaillée entre MEF et Unity et comme il s'agit d'un grand tableau avec un formatage, veuillez le lire sur cette page.
http://akashkava.com/blog/391/mef-vs-unity-in-composite-application-prism/