Having browsed through the ember and ember-data code, I find that there appears to be a “fear” of defining new classes to handle new concerns. Mostly the code is organized in a very flat fashion, and using mixins to a great extend. I think the code would be much easier to understand and much easier to contribute to if it was organized in a more OO fashion.
As an example, looking at the store.js DS.Store class, it is almost 1500 lines long, with perhaps around 60+ methods and counting… I don’t see how this can adhere to “Single Responsibility”? Why not split up the create, update and find/query parts into separate classes. Then use mixins for these classes for shared concerns/logic such as transactions and adapter etc. The didXXXX methods also logically belong together.
Same goes for the Ember Router/Route implementation which also seems to bundle too many varied concerns together under these two main classes. I think a new architecture approach using more of an OO design would really clean up the code bade and allow for much more flexibility and better understanding (including newcomers to the project). With a better/cleaner architecture it would be easier to understand the code and easier to contribute. A class should rarely have more than 10 functions in my experience (if been programming for over 25 years).
I do understand however that the project is under a lot of stress, has many contributors and are pushing for a 1.0 release. I just hope that the 1.1, 1.2 or 2.0 release will gradually introduce a much better OO architecture with a clearer separation of concerns. Of course we gotta start somewhere