Ich bin dabei, einen Windows-Dienst zu erstellen, der MEF implementiert. Die Idee ist, dass der Dienst Unterkomponenten verwalten und steckbar sein soll, wobei eine beliebige Anzahl neuer Komponenten zur Laufzeit eingeführt werden kann, ohne dass ein vollständiges Kompilierungsszenario für Neukompilierung und Bereitstellung durchlaufen werden muss. Die Komponenten sollten steckbar sein, was bedeutet, dass sobald ich eine Ausgabe-Assembly in einen bestimmten Ordner auf der Disc verliere, der Windows-Dienst "Hey, hier ist eine neue Komponente zum Ausführen ..." sagen sollte und es einfach machen sollte. Das ist die Stärke von MEF. Sehr cooles Zeug bis jetzt.Microsoft Extensibility Framework - MEF CompositionContainer
Ich verstehe das Konzept der Erstellung eines AggregateCatalog und eines CompositionContainer zum Importieren aller verfügbaren Unterkomponenten (Assemblys). Das ist alles gut und es funktioniert wie erwartet, wenn der Windows-Dienst gestartet wird. Ich werde jedoch irgendwann neue Komponenten zur Laufzeit einführen, daher werde ich irgendwann den CompositionContainer brauchen, um neue Ausgabemodule zu erkennen, die hinzugefügt werden.
Meine Bedenken mit dem Folgenden sind irgendwelche Auswirkungen auf die Leistung. Ist es sicher/effizient die CompositionContainer Logik in einer Schleife zu setzen, wie die folgenden:
[ImportMany(AllowRecomposition = true)]
private IEnumerable<Lazy<IMySubComponentTask, IDictionary<string, object>>>
MySubComponentTasks { get; set; }
while (true)
{
//Create a general aggregate catalog
var catalog = new AggregateCatalog();
//Adds all the parts found in the same assembly as the Program class
catalog.Catalogs.Add(new AssemblyCatalog(typeof(MySubComponentTaskFactory).Assembly));
//Create a new directory catalog
var directoryCatalog = new DirectoryCatalog(@".\Extensions");
//Add the DLLs in the directory to the aggregate catalog
catalog.Catalogs.Add(directoryCatalog);
//Create the current composition container to create the parts
var container = new CompositionContainer(catalog);
//Fill the imports of this object
try
{
container.ComposeParts(this);
}
catch (CompositionException compositionException)
{
Console.WriteLine(compositionException.ToString());
}
}
Jede Art von Feedback oder Eingabe wird geschätzt.
Danke, Mike
Danke, ich würde wahrscheinlich diesen Weg gehen. Hier ist noch eine Sache, die ich der Kürze halber nicht erwähnt habe. Für jede Unterkomponente, die der CompositionContainer bei jeder zeitgesteuerten Suche entdeckt, werde ich den Unterkomponentenjob in einen separaten Thread umwandeln. Um die Anzahl der neu erstellten Threads zu verwalten, muss ich prüfen, ob ein Thread bereits einen Unterkomponentenjob ausführt, der bei einer vorherigen zeitgesteuerten Suche erkannt wurde. Was ist Ihre Erfahrung mit Threads und wie viele Threads ist zu viel? Irgendwann habe ich möglicherweise 15+ Sub-Komponenten für dieses Ding –
@michael: Die maximale Anzahl der Threads hängt von der CPU und Core-Architektur. Ich würde auf die Task Parallel Library verweisen, um das Komponenten-Threading zu verwalten. – IAbstract