Registrierung von IoC-Containern aus mehreren Baugruppen

Question

Ich versuche zu verstehen, was Best Practice für die Registrierung der Objekte in IOC-Container aus verschiedenen Projekten einer Lösung ist.

Ich habe eine Lösung mit 4 Projekten, und ich sah die Projekte eine Lösung zu schaffen Installateure in jedem und dann an einem Ort Anruf somtehing wie folgt aus:

_container = new WindsorContainer(); 
      var assemblyNames = new[] {"Dal", "Utils" }; 
      _container.Install(assemblyNames.Select(
        x => (IWindsorInstaller)new AssemblyInstaller(Assembly.Load(x), 
         new InstallerFactory())).ToArray()); 

Aber auch sah ich eine Lösung, die in jedem Projekt gibt es eine Erstellung von Container, und im Inneren gibt es eine Registrierung der Objekte, die für dieses spezifische Projekt relevant sind.

Meine Frage ist: Was ist die beste Praxis für diese Situation?

Answer 1

Wir haben hier ein Beispiel: Eine Web-Lösung, die aus vielen Projekten besteht: Ein Kernprojekt und viele andere, die auf den Kern verweisen. Alle von ihnen landen in verschiedenen Ordnern (oder kopiert nach dem Build in den Core/bin, wenn Sie möchten). Zur Startzeit laden wir sie dynamisch und laden dann die IWindsorInstaller von ihnen. Wir laden dlls wie folgt aus:

public static void LoadMoules() 
{    
    string basePath = AppDomain.CurrentDomain.BaseDirectory; 
    string binPath = Path.Combine(basePath, "bin"); 
    DirectoryInfo binFolder = new DirectoryInfo(binPath); 
    IEnumerable<FileInfo> binFiles = binFolder.EnumerateFiles("*.dll", SearchOption.AllDirectories); 
    Assembly[] domainAssemblies = AppDomain.CurrentDomain.GetAssemblies(); 
    try 
    { 
     foreach (var binFile in binFiles) 
     { 
      AssemblyName assemblyName = AssemblyName.GetAssemblyName(binFile.FullName); 
      if (domainAssemblies.All(x => x.FullName != assemblyName.FullName)) 
      { 
       Assembly.Load(assemblyName.FullName); 
       Debug.WriteLine($"Loading {assemblyName.FullName}"); 
      } 
     } 
    } 
    catch (Exception exception) 
    { 
     DynamicModuleLoaderEventSource.Log.FailedToLoadAssembly(exception.Message + exception.StackTrace); 

    } } 

Dann wir die Anmeldungen erhalten:

try 
    { 
     foreach(Assembly moduleAssembly in installationModules) 
     { 
      // satellite proejct assemblies 

      Debug.WriteLine(moduleAssembly.FullName); 
      ContainerRegisterEventSource.Log.InstallAssembly(moduleAssembly.FullName); 
      container.Install(FromAssembly.Instance(moduleAssembly)); 
     } 

     container.Install(FromAssembly.This()); // the core assembly 
    } 
    catch(Exception exception) 
    { 
     ContainerRegisterEventSource.Log.Exception(exception.Message + exception.StackTrace); 
     Trace.WriteLine("SetupContainerForMigrations error : " + exception.Message + Environment.NewLine + exception.StackTrace); 
    } 

es auf diese Weise tun Sie mit einem Behälter mit allen Abhängigkeiten enden.

Answer 2

Normalerweise erstelle ich ein Projekt, das die meisten meiner freigegebenen Ressourcen wie Modelle, Bibliotheken und auch die IoC-Konfiguration enthält, die ich in den anderen Projekten verwende. Durch das Konfigurieren des IoC-Containers aus diesem Projekt erspare ich mir ein wenig Kopieren. Damit behalte ich die Möglichkeit, die Konfiguration aus dem Projekt zu überschreiben, in dem Sie diese Konfiguration verwenden.

Am Ende geht es um Wartbarkeit. Wenn Sie die gleichen Abhängigkeiten in allen Ihren Projekten verwenden, wäre es ein Dorn im Auge, es für jedes einzelne Projekt zu konfigurieren.

Answer 3

Jedes ausführbare Projekt sollte einen eigenen Container haben, da es unabhängig von anderen ausführbaren Projekten ausgeführt werden kann. Bibliotheksprojekte stellen normalerweise Abhängigkeiten bereit, die im ausführbaren Projekt verbraucht werden. Daher ist das ausführbare Projekt dafür verantwortlich, diese Abhängigkeiten in seinem Container zu registrieren, wenn es diese verwenden möchte, wobei die Bibliothek keinen eigenen Container besitzt. Wenn mehrere Container unterschiedliche Probleme verursachen, beispielsweise wenn eine Klasse als Singleton registriert ist (ein Verweis, der von allen Konsumenten der Abhängigkeit gemeinsam genutzt wird) und mehrere Container enthält, würde dies zu mehreren Instanzen der Klasse führen, die gerade erstellt wird in jedem Container)

Es könnte auch ein Problem verursachen, wenn es projektübergreifende Abhängigkeiten gibt, da der Container eine in einem anderen Container registrierte Abhängigkeit nicht auflösen kann.