✅ Allowing option of using dependency injection
I'm working on a small-ish project, mostly for personal use. I have a 'core' type called
ILazyGenerator and a corresponding ILazyGeneratorBuilder type, both with 'default' concrete implementations in the same project. These default concrete types or interface don't inherently provide any support for dependency injection, but in the slim case that someone else who maybe eventually possibly perhaps is going to use my library wants dependency injection, I might want to support that. However, I really want to keep this initial project relatively small and simple, and not have to bring in huge packages like MS.Ext.DI. So there are two possibilities I'm considering: either I have the interfaces a mess of generics which provide support for generic context objects everywhere, or I just bite the bullet and include standard support for DI using MS.Ext.DI in the base library. Obviously the latter is easily the simpler of the two, however I still would like some feedback.5 Replies
when you say huge what you mean?
size or complexity?
cause that package is 250 kb
I don't understand why code for interfaces in a class library would need to do anything related to dependency injection.
Well, the interfaces don't.
As long as your concrete types take their dependencies as constructor parameters they should work with dependency injection.
I'm not sure why you would need any reference to the DI framework.
Let the consumer choose how they actually use DI, if at all.
Okay I think I would have to explain my project in more detail for this question to actually make sense.
And idk how I would explain it without just showing the entire project.
eh, I'll try asking this at a later point when I hopefully can explain it better