I have a c# application set up like so:
[Assembly-ConsoleApp] --References--> [Assembly-Domain]
/
[Assembly-FileAccess] --References-->---------/
Basically, most of my interfaces and a few concrete classes are found in the Domain assembly, with many of the concrete implementations found in the FileAccess assembly. The ConsoleApp assembly makes use of the Domain assembly with no references to the FileAccess assembly.
I've created an autofac FileAccess module to wire up FileAccess implementations with the Domain interfaces, along with any concrete classes directly inside the Domain assembly. My question is where to put this module. From a best practices perspective, should the module be in the FileAccess assembly (which would require me adding a reference/dependency on the autofac assemblies) or should it go in the ConsoleApp assembly (which makes use of the module and already has an autofac dependency)? Or would a totally separate assembly that just has the given module make sense?
Thanks
A container should only be referenced from the application's Composition Root, which in your case means the ConsoleApp assembly.
This ensures that assemblies that contain the application logic are kept free of any dependency on any particular DI Container.
You could also implement the module in a separate assembly and load that from the Composition Root, but since that assembly (the ConsoleApp) still needs a reference to Autofac, not much is gained from doing that. It depends a bit on the scenario in question, but unless you are creating an ISV application that ships as a piece of (virtually) shrink-wrapped software to many uncontrolled customers, it's rarely worth the effort.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With