I am trying to figure our where the code for configuring my dependency injection container for my domain repository services lives.
My initial thought was to let the client configure all services, but then the client needs to be aware of the repository service, which I don't want to expose in the client.
I was thinking that each layer could configure its own service dependencies via an exposed configuration method or class?
My initial thought was to let the client configure all services, but then the client needs to be aware of the repository service, which I don't want to expose in the client.
What I tend to do is still follow the Composition Root pattern, where my web project would be the first place where the IoC wiring-up would start (i.e. the usual sort of 3rd party library that would hook itself into the controller factory). But I then configure the rest of my IoC bindings by referencing an IoC module (in my case I usually use Ninject, so I reference a NinjectModule from my web project). But I put this NinjectModule in a separate infrastructure project.
I can then reference this IoC infrastructure project from my web project and the IoC project can reference every other project in the solution.
This way I don't have to create project references in my web project to things I might not want my web project to access, like my repository layer.