Ich habe ein einfaches .NET-Projekt und frage mich, was der beste Ansatz für das Bootstrapping von Unity ist. Ich habe mit einer WebApp mit einer Reihe von Controllern begonnen. Jeder dieser Controller verfügt über eine eigene Handler-Klasse, an die der Controller die Implementierung delegiert. Etwas in den Zeilen von:

public class UsersHandler : IUsers
{
    IAuthenticationClient authenticationClient;
    ILogger logger;

    public UsersHandler(IAuthenticationClient authClient, ILogger logger) { ... }       
}

In der Application_Start-Methode von Global.asax erstelle ich den UnityContainer und registriere Typen. Es gibt ein zweites Projekt (Class Library), bei dem es sich im Grunde um die Business-Schicht handelt.

Ich habe jetzt eine neue Klassenbibliothek erstellt (nennen wir sie 'XYZ'), um eine andere Verantwortung der Anwendung zu übernehmen. DI wird auch hier verwendet.

Für den Anfang habe ich eine Singleton-Klasse erstellt, die als Einstiegspunkt für dieses Projekt dient, in dem ich den UnityContainer instanziiere und Typen registriere.

Nun, dass ich diese Funktion habe, begann ich mich zu fragen, wer die Typregistrierung handhaben sollte, was bedeutet, was das Composition Root meiner Anwendung sein sollte. Die WebApp wäre die erste Wahl, aber dafür müsste ein Verweis auf das 'XYZ'-Projekt hinzugefügt werden, der sich nicht richtig anfühlt, da dies von der Business-Schicht verwendet wird.

1) Soll der Composition-Stamm eine neue Klassenbibliothek sein, die sowohl auf die WebApp als auch auf 'XYZ' verweist und in der global.asax meiner WebApp initialisiert wird? Dies würde jedoch zu einer zirkulären Abhängigkeit führen, da dieses Bootstrapper-Projekt die WebApp kennt und umgekehrt.

2) Was ist, wenn ich eine Abhängigkeit im 'XYZ'-Projekt auflösen muss? Derzeit habe ich eine Instanz der UnityContainer-Klasse, daher kann ich Folgendes tun:

var logger = container.Resolve<ILogger>();

Ist das überhaupt eine gute Übung?