I see a lot questions around the use of dependency injection but never understand the purpose. Why do we need extra code to make this work:
this.store.filter(...)
while all we need is
App.store.filter(...)
Other than some syntactic sugar, and forcing decoupling, I don’t see any apparent reasons for this (but I am new). Does this make testing easier, or design more modular, or prototyping new apps more hassle free? Not quite sure.
The downside of this approach is it makes the framework so much more complex. Thinking more broadly, why people often consider Ember having a steep learning curve, in my opinion, is it is full of this kind of “unique features”. Imagine if we don’t have dependency injection, how many questions would have been eliminated here in the forum.
Decoupling is a big one, but also Ember is making a push away from namespacing and more towards ES6-based modules. If you already haven’t, take a look at Ember App Kit. There is no longer this concept of App as a global to hang objects off of. Instead it makes use of Ember’s container to track and manage object creation.
One major advantage is the power it gives you in unit testing that would be otherwise difficult/hacky without DI. Allowing you to create isolated containers of objects specific towards your test, rather than initializing the entire application.
The web has undoubtedly been perceived as wild wild west of software development, and I’m glad we’re now turning the corner to building well-structured, testable, applications.