Tengo un proyecto .NET simple y me pregunto cuál es el mejor enfoque para el arranque de Unity. Comencé con una aplicación web con un montón de controladores. Cada uno de estos controladores tiene su propia clase Handler a la que el controlador delega la implementación. Algo en las líneas de:

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

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

En el método Application_Start de Global.asax, estoy creando UnityContainer y registrando tipos. Hay un segundo proyecto (Biblioteca de clases) que es básicamente la capa Business.

Ahora creé una nueva biblioteca de clases (llamémosla 'XYZ') para manejar una responsabilidad diferente de la aplicación. DI también se está utilizando aquí.

Para empezar, creé una clase Singleton que serviría como un punto de entrada para este proyecto donde instanciar el UnityContainer y registrar tipos.

Ahora que tengo esto funcionando, comencé a preguntarme quién debería manejar el registro de tipo, es decir, cuál debería ser la raíz de composición de mi aplicación. La aplicación web sería la primera opción, pero eso requeriría agregar una referencia al proyecto 'XYZ' que no se siente bien ya que esto es utilizado por la capa empresarial.

1) ¿Debería la raíz de composición ser una nueva biblioteca de clases que haga referencia tanto a la aplicación web como a 'XYZ' y se inicialice en el global.asax de mi aplicación web? Sin embargo, eso causaría una dependencia circular ya que este proyecto Bootstrapper conocería la aplicación web y viceversa.

2) ¿Qué sucede si necesito resolver una dependencia en el proyecto 'XYZ'? Actualmente tengo una instancia de la clase UnityContainer, así que puedo hacer esto:

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

¿Es esta una buena práctica de todos modos?