10 ms·

DI/IoC gets complicated, fast. hand rolling DI, yep brilliant, generally quite easy to work your way through because it's easy to see where classes are being u

DI/IoC gets complicated, fast. hand rolling DI, yep brilliant, generally quite easy to work your way through because it's easy to see where classes are being used. Hand rolling can get complicated when your applications get BIG and you want to do fancy things like having modular code (whether you ever use the module somewhere else or not) or lazy loading or multiple scopes. Then you use a framework and you find your dependencies take dependencies, your wireup code is auto-magical, you inject dependencies into private properties, you want multiple implementations of particular interfaces but want to ensure only the right one gets used in each circumstance. Then multiple people start getting their fingers into the pie and the DI/IoC explodes into config files throughout the application, and the only way to understand what's being wired up without a map, is to "find usages", pin files, and cry (I'm not bitter or anything ;) DI/IoC can work wonders for handling complexity, it can also increase your complexity if you aren't very careful)

vbsteven 8y ago
That last sentence is the important part: "if you aren't very careful". I work in multiple large java/spring codebases and the rule we use is "Keep all configuration related to the same base type/interface in the same file". That way if you want to find out which logger is injected you only have to check 1 file. Another easy way to find out what is injected at runtime is to attach a debugger and set a breakpoint.
- thisone 8y ago
  :( with the particular project I've been looking through, trying to debug via running the entry point was a non-starter. The part of the system I needed to trace would only be able to run if I had 4 other services running (all started seperately from the same main file) and a full dataset loaded. Once I finally discovered a hint about which files governed the behaviour I was investigating I was finally able to isolate the tests to begin the debug cycle. Sometimes it's just complicated.

vbsteven 8y ago

That last sentence is the important part: "if you aren't very careful". I work in multiple large java/spring codebases and the rule we use is "Keep all configuration related to the same base type/interface in the same file". That way if you want to find out which logger is injected you only have to check 1 file. Another easy way to find out what is injected at runtime is to attach a debugger and set a breakpoint.

thisone 8y ago
:( with the particular project I've been looking through, trying to debug via running the entry point was a non-starter. The part of the system I needed to trace would only be able to run if I had 4 other services running (all started seperately from the same main file) and a full dataset loaded. Once I finally discovered a hint about which files governed the behaviour I was investigating I was finally able to isolate the tests to begin the debug cycle. Sometimes it's just complicated.