MEF, Erstellen von Import des Baumes, wenn eine Verzweigung angefordert

Question

Mit MEF Ich möchte folgendes tun.

Ich habe eine WPF-Shell. Um die Shell möchte ich von einem anderen DLL ein Usercontrol importieren, die auch ein Blick auf meine MVP Triade ist. Die Art und Weise der MVP Triade funktioniert, ist, dass in Präsentator ich einen Konstruktor haben, der sowohl IModel und IView und Drähte ihnen nimmt. Also, für diese zu arbeiten, um, ich brauche MEF Folgendes zu tun:

1. Erstellen IView Implementierung
2. Erstellen IModel Implementierung
3. Presenter erstellen und IModel und IView an den Konstruktor übergeben
4. Import IView Implementierung in meine Schale, wenn es wird angezeigt

Stattdessen, was es tut, ist es nur die Art schafft exportieren IView und übergibt sie an der Schale, im Grunde die Schritte 2 und 3. Es ist ziemlich logisch überspringen, wenn man darüber nachdenkt, aber wie kann ich MEF sagen, auch das schaffen ganze Triade, wenn ich fragen Sie nach einem IView. Ich brauche nicht Presenter noch Modell anderswo in meiner Shell zu verweisen .dll es als Import auch so Puting ist keine Option (und es wäre ziemlich hässlich trotzdem:).

Ich bin mit dem neuesten Tropfen MEF (Preview 2 Refresh). Anyone?

== == aktualisieren

Ich habe eine Lösung gefunden, und ich darüber gebloggt hier:
Krzysztof Kozmic Blog - Erstellen Baum von Abhängigkeiten mit MEF

Allerdings würde ich mehr als glücklich sein, wenn jemand mit einer besseren Lösung kommt. **

Answer 1

Überprüfen Sie meine Antwort hier.

http: // codebetter .com / blogs / glenn.block / Archiv / 2008/11/12 / mvp-mit-mef.aspx

EDIT: ( aus dem Link hinzugefügt, um zu verhindern nicht als niedrige Qualität / LOA gekennzeichnet wird )

   1: using System.ComponentModel.Composition;
   2: using System.Reflection;
   3: using Microsoft.VisualStudio.TestTools.UnitTesting;
   4:  
   5: namespace MVPwithMEF
   6: {
   7:     /// <summary>
   8:     /// Summary description for MVPTriadFixture
   9:     /// </summary>
  10:     [TestClass]
  11:     public class MVPTriadFixture
  12:     {
  13:         [TestMethod]
  14:         public void MVPTriadShouldBeProperlyBuilt()
  15:         {
  16:             var catalog = new AttributedAssemblyPartCatalog(Assembly.GetExecutingAssembly());
  17:             var container = new CompositionContainer(catalog.CreateResolver());
  18:             var shell = container.GetExportedObject<Shell>();
  19:             Assert.IsNotNull(shell);
  20:             Assert.IsNotNull(shell.Presenter);
  21:             Assert.IsNotNull(shell.Presenter.View);
  22:             Assert.IsNotNull(shell.Presenter.Model);
  23:         }
  24:     }
  25:  
  26:     [Export]
  27:     public class Shell
  28:     {
  29:         private IPresenter _presenter = null;
  30:         
  31:         public IPresenter Presenter
  32:         {
  33:             get { return _presenter; }
  34:         }
  35:  
  36:         [ImportingConstructor]
  37:         public Shell(IPresenter presenter)
  38:         {
  39:             _presenter = presenter;
  40:         }
  41:     }
  42:  
  43:     public interface IModel
  44:     {
  45:     }
  46:  
  47:     [Export(typeof(IModel))]
  48:     public class Model : IModel
  49:     {
  50:         
  51:     }
  52:  
  53:     public interface IView
  54:     {
  55:     }
  56:  
  57:     [Export(typeof(IView))]
  58:     public class View : IView
  59:     {
  60:     }
  61:  
  62:     public interface IPresenter
  63:     {
  64:         IView View { get;}
  65:         IModel Model { get; }
  66:     }
  67:  
  68:     [Export(typeof(IPresenter))]
  69:     public class Presenter : IPresenter
  70:     {
  71:  
  72:         private IView _view;
  73:         private IModel _model;
  74:  
  75:         [ImportingConstructor]
  76:         public Presenter(IView view, IModel model)
  77:         {
  78:             _view = view;
  79:             _model = model;
  80:         }
  81:  
  82:         public IView View
  83:         {
  84:             get { return _view; }
  85:         }
  86:  
  87:         public IModel Model
  88:         {
  89:             get { return _model; }
  90:         }
  91:  
  92:     }
  93: }

Also, was ist hier los?

Shell wird mit Presenter injiziert. Moderator wird mit Ansicht und Modell injiziert. Alles hier ist Singletons, muß aber sein nicht.

Der Unterschied zwischen unseren beiden Beispielen ist, dass der Moderator in die Schale eingespritzt wird immer statt der Ansicht. Wenn der Presenter Erstellen der Ansicht, dann können Sie nicht nur die Ansicht greifen zuerst (wie er tat) oder der Moderator wird nicht erstellt bekommen. Nun, Sie können es tun, aber Sie am Ende es zu Bits Hacking. Cleaner ist nur das Presenter zu injizieren und haben sie einen IView aussetzen. Wir taten dies in Prism und es funktionierte ganz gut.

Answer 2

Wie Sie in Ihrem Blog-Eintrag skizziert ist die absolut gültige Weise MEF zur Nutzung. Dies ist verschachtelte Komposition und bei der Gestaltung ist es immer gut im Auge zu behalten, dass Container der Decider ist, so als Plug-in / Extender-Anbieter auf dem Dienste konzentrieren, die Sie „Export“ und als ein wichtiger, Sie shouldn ‚t Sorge über das, was Sie gewartet werden müssen, oder‚Import‘(dieser Punkt einige Probleme in dem letzten Tropfen hat, aber ich höre gut genug zu sein, optimistisch, was es).

So in verschachtelten Komposition, können Sie einige externe Dienste benötigen aber zur Zeit können Sie auch einige bieten werden. Wenn Sie eine compose tun, wird es alles zusammen stecken.

Ich habe eine Blog-Post, die 2 Beispiele diese Denkweise veranschaulichen:

http://www.sidarok.com/web/blog/content/2008/09/26/what-is-this-managed-extensibility-framework-thing-all-about.html

, auch die DLL fallen zu lassen und die Arten darin sehen, können Sie DirectoryPartCatalog verwenden diese Ordner zu sehen.

Sie müssen auch die Szenarien beobachten, wo es mehrere Exporte für den gleichen Vertrag sind, und das Recht, einen von Metadaten zur Verfügung gestellt bestimmen.