So, to start, I would say that I agree with you that I like my DI logic for my application centralized, whether it's in a single or few classes or in a single o

So, to start, I would say that I agree with you that I like my DI logic for my application centralized, whether it's in a single or few classes or in a single or few XML files. On the other hand, people who use @Autowired or @Inject are doing the opposite; they are scattering their DI logic throughout the application, which I very much do not prefer. That said, the DI analogy breaks down a little bit when you consider that Scala implicit resolution happens at compile-time and is lexically scoped. As such, you can't override implicits that are created/resolved in other source files without editing those source files directly. You can only affect the implicits in your source files by using imports or defining implicit overrides. If you want a full-blown compile-time DI framework with centralized logic in a single location, then Scala's MacWire library seems to be the best example: https://github.com/adamw/macwire https://github.com/adamw/macwire Scala's implicits can be seen as some kind of lightweight DI system, but it is definitely not meant to be used to wire together an application at the top-level.