Suchen Sie den richtigen Kompositionswurzel für eine .NET-Bibliothek

Dies hängt vom Typ der Bibliothek ab, die Sie erstellen. Ist Ihr Bibliotheksprojekt ein Teil Ihrer eigenen Lösung oder ist es eine wiederverwendbare Bibliothek, auf die andere Entwickler außerhalb Ihres Teams, Ihrer Abteilung oder sogar Ihrer Organisation angewiesen sind?

Wenn es sich nur um einen Bibliotheksprojektteil einer Lösung handelt, sollte das Bibliotheksprojekt selbst normalerweise keinen Kompositionswurzel enthalten. Per Definition ist der Kompositionswurzel ein (vorzugsweise) eindeutiger Ort in einer Anwendung, in der sich Module befinden zusammen komponiert ". Mit anderen Worten, Ihre Lösung würde ein oder mehrere Start-up-Projekte (z. B. eine MVC-Anwendung, WCF-Dienst, Konsolenanwendung) haben, und jedes Start-up-Projekt würde seinen eigenen Kompositionsstamm erhalten. Die darunter liegenden Ebenen erhielten keine eigene Kompositionswurzel.

Dies bedeutet übrigens nicht, dass Sie die Code-Duplizierung in den Kompositionswurzeln nicht verhindern sollten. Wenn durch eine Standardverkabelung für eingeschlossene Projekte (wie DAL und BLL) viele Duplizierungen verursacht werden, sollten Sie diese Logik normalerweise in ein anderes Projekt extrahieren. Sie können dies entweder tun, indem Sie einen Teil der Registrierungslogik in eines der Projekte (am wahrscheinlichsten die BLL) einfügen und jeden Kompositionswurzel diese geteilte Logik nennen lassen, oder Sie können dies tun, indem Sie ein spezielles Bootstrapper-Projekt für dieses Projekt hinzufügen die referenzierten Projekte. Dieses Bootstrapper-Projekt enthält nur die Registrierungslogik. Durch das Trennen dieser Logik von den Anwendungsassemblys verhindern Sie, dass diese Assemblies eine Abhängigkeit von der verwendeten Abhängigkeitsinjektionsbibliothek benötigen. Es ist jedoch normalerweise kein Problem, wenn eine Assembly eine Abhängigkeit von einer solchen Bibliothek annimmt, solange Sie sicherstellen, dass die Anwendungslogik keine Abhängigkeiten vom Container aufnimmt.

Bei wiederverwendbaren Bibliotheken sind die Dinge normalerweise anders. In diesem Fall werden die Verbraucher Ihre Bibliothek verwenden, aber Sie haben keine Kontrolle darüber, wie sie ihre Anwendung strukturieren. Sie möchten die Bibliothek oft so bereitstellen, dass sie direkt von den Verbrauchern konsumiert werden kann, ohne dass Sie alle Arten von "komplexen" Registrierungen in ihrer Kompositionswurzel vornehmen müssen. Sie wissen oft nicht einmal, ob sie überhaupt eine Kompositionswurzel haben.

In diesem Fall sollten Sie Ihre Bibliothek normalerweise ohne einen DI-Container arbeiten lassen. Sie sollten selbst nicht von einem solchen Container abhängig sein, da dies den Container in den Container ziehen würde. Wenn Sie einen Container verwenden, sollten Sie sich fragen, warum Ihre wiederverwendbare Bibliothek einen Container verwendet, und falls dies erforderlich sein sollte. Vielleicht tun Sie das, weil Sie alle Arten um das Prinzip der Abhängigkeitsinjektion herum entworfen haben; weil das Testen einfacher macht. Vergiss nicht, dass dies dein Problem ist, nicht das Problem deiner Konsumenten. Als wiederverwendbarer Bibliotheksdesigner sollten Sie Ihre Bibliothek so gut wie möglich für Ihre Kunden nutzbar machen. Bitte gehen Sie niemals davon aus, dass Ihre Kunden einen DI-Container verwenden. Selbst wenn sie Dependency Injection praktizieren, wenden sie Pure DI anstelle eines DI Containers an

Wenn Sie eine wiederverwendbare Bibliothek erstellen, werfen Sie einen Blick auf diesen Blog Beitrag von Mark Seemann.