I am creating the service where I am using DI container as an entry point.
My solution is getting heavy what forced me to think how to do unity registration in good way.
I have Service with couple of other dlls with logic. As for now, Unity is installed only in Service where all registration is done.
My service needs to refer all dlls which are needed for DI registration and all nugets installed and used by refereed dlls in DI.
It ends up with pretty heavy packages.config in Service which are needed only for DI registration and it is hard to recognize what is used by service itself and what is not.
I am wondering if there is other way, more cleaner way to do registration without huge list of references in main project and do not brake good practice roles at the same time.
I came up with two solutions: 1 - Create separate dll only for UnityConfiguration, I could have there one public static class like: UnityConfiguration.RegisterComponents() which would be called by Service. In that solution I still will have huge list of reference to all the stuff, but it will be at least separated from main service...
2 - Solutions which probably will not be supported by anyone (by me as well): I would have Unity installed in each dll with logic and each dll could have its own static class UnityConfiguration.RegisterComponents() and main service would call all that registration without knowing the types...
Can you please share your way you would go for ? I am really interested in your opinion...