0

I have 4 projects in my Clean Architecture solution:

  • Domain
  • Application
  • Infrastructure
  • Presentation.API

I have a method in each of these projects called Add{projectName} such as AddInfrastructure(services) which takes in IServiceCollection and wires up all it's classes.

My Presentation Layer has a project reference to Domain & Application however I want to call AddInfrastrcuture without having a project reference to my Infrastructure project.

I know a project reference is the easiest options however I don't want any of my Infrastrcutrue classes to be available in my Presentation layer. Is there anyway I can my infrastructure layer classes to my service collection without having to have a project reference? Something with reflection or assembly scanning?

Ryan Gaudion
  • 695
  • 1
  • 8
  • 22
  • 3
    See [Ioc/DI - Why do I have to reference all layers/assemblies in application's entry point?](https://stackoverflow.com/a/9503612). You are overcomplicating this by worrying about application layers, which runs counter to what dependency injection is used for - specifically, for flattening the dependency graph to make it simple to manage. – NightOwl888 May 19 '22 at 16:47
  • You can call AddInfrastructure in Application layer. This way only Application layer will have reference to it. – funatparties May 19 '22 at 17:04
  • @funatparties: that's not true. Project/assembly references are transitive. This means that if Presentation depends on Application and Application depends on Infrastructure, it implies that Presentation also depends on Infrastructure. – Steven May 19 '22 at 19:29
  • 1
    @Steven yes of course you will have a transitive dependency, but no matter which approach you take you will have dependency in some way. Even if some library at the leaf level of the dependency tree is broken, your whole software is automatically broken no matter how you invoke it. – funatparties May 19 '22 at 20:24
  • @funatparties, you won't necessarily have that dependency from API layer to infrastructure. How to achieve this is discussed in the answers that NightOwl888 pointed to in his previous comment. – Steven May 20 '22 at 13:32
  • @Steven I completely understand what you are saying. I know you won't have the direct/transitive dependency at compile time, but then at the first moment the infrastructure class is required, you become dependent on it. And in the 99.999% of the systems it's much better to have this information at compile time. This would only be not true when your system has a requirement to dynamically load different dlls at runtime which is very rare. – funatparties May 20 '22 at 18:17
  • @funatparties, as I noted [here](https://stackoverflow.com/a/9505530/264697) the way to prevent the dependency from the API assembly to the infrastructure assembly is to move the [Composition Root](https://freecontent.manning.com/dependency-injection-in-net-2nd-edition-understanding-the-composition-root/) layer and API layer both to different assemblies. After that the Composition Root can take a dependency on all assemblies, while the assembly that API resides in can be free of that dependency. Whether this is useful though.... is a different discussion. – Steven May 21 '22 at 10:38

0 Answers0