4 ms·
> The reason why we have DI and DI frameworks is because we are asked in requirements to make things configurable out-of-code (and at runtime) That's a reason,
by HereBeBeasties 7y ago
> The reason why we have DI and DI frameworks is because we are asked in requirements to make things configurable out-of-code (and at runtime)
That's a reason, but it's far from the only one. The way I've seen DI used over the years is far more about separating out concerns in the code via interfaces, or making things testable without side effects, than it is making those things dynamically pluggable / controllable via config, not code. The majority of interfaces passed as dependencies into constructors have a single real implementation (outside of unit tests).
I lately err on the side of explicit manual wiring as the cost saving of doing it all automatically does not usually offset the costs of extra magic and lack of compile-time safety that it incurs. Exceptions are where there is a lot of AoP interceptor stuff to wire in, or if I want something to help with lifecycle scoping (e.g. per-request lifetime for a set of related things), at which point a DI framework will likely start paying for itself.
- mrec 7y agoI generally share your view, and have never really understood the appeal of the magic woo frameworks. I asked an interview candidate about this once (he'd spoken positively about them) and he very honestly said that yep, it's all about bypassing change control restrictions. Which is a pragmatic reason, but not a good one at the organizational level. It's every bit as easy to break your system via a config change as via a code change.
- UK-Al05 7y agoI don't how a IoC container would allow you bypass change control? Because config is not covered by change control in your case?
- mrec 7y agoTheir case, not mine, but yes, I gathered that change control could be skipped for "config-only" changes. Don't ask me why, it sounded crazy to me too.
- mywittyname 7y agoI've always found passing objects explicitly to be superior to DI when it comes to unit testing as well. Build the object you want, then test any expected side-effects of the method. And if you can't construct an object exactly as needed, then mock objects work almost as well.
- mateuszf 7y agoIt's not superior, because it's still DI but manual not automatic.