Difference between Ember objects and Ember Data ones

Question

What's the difference between Ember Objects and the ones from Ember Data? I know that I should use Ember Data models when there is some data on the server, but when and where should I use either of them?

Answer 1

Note: This is rather long, biased and represents my own opinion on this matter. May not be the answer.

The type Object is what you could call the most "simple" object type in Ember. It has the most essential features you would likely use in modern applications like computed properties and observables. And allied to the runtime it also allows bindings, filtering, etc. I would call it the general purpose object, which can be extended to create other types, can also be combined with mixins to further enhance its usage. It has a great but finite number of features, but I wouldn't call it backend friendly, only because I know of DS.Model and its features.

Ember-Data's DS.Model heavily extends the features in Object in order to provide more features that make sense when working with backend data in (most cases) a RESTful environment. Much like an object supported by an ORM (e.g.: .NET's EntityFramework or Ruby's ActiveRecord), it provides a set of features so the objects of that type (DS.Model) can be managed through a data store (DS.Store), and beyond the features already present in an Object it will allow state management (isDirty, isNew, isError, isNew, etc), the ability to commit and rollback and object in a store (and subsequently the backend API), relationships/associations, etc.

If you are using Ember-Data at all, you should use the type Model, since it (was intended to be used with the store, and) uses the model type on sideloading, associations, plurals and throughout the whole AJAX request/response workflow. In fact, one of the advantages of using a Model backed by a Store is exactly this: Have the framework do the heavy lifting by building the AJAX request to the correct RESTful resource on its own, managing the response, do the sideloading of the JSON payload into an object of the correct type, while giving you a promise that you can use the model while the data is being requested/processed/materialized (so you can transition views/routes while this is happening).

It also gives you a great deal of convenient features within the store backed object itself (e.g.: record.deleteRecord(); store.commit()) and in the end of the day, makes us more productive and we can build applications a lot faster.

With that said, there is criticism of this approach because a large number of developers usually don't like or don't feel confortable resorting to what people call technomagic; in other words, they don't feel like using it because they feel they are not 100% in control of what happens under the hood. In my personal opinion, at the same time I can see where these people are coming from, I believe Ember-Data does nothing be help me to be more productive and the only things it asks in return is that I am consistent with my code and that I follow certain conventions and I'm happy with that.

Back to the Object, if you are not using Ember-Data, you should use the Object type as your models. This means that you will have do all of these tasks manually (generally not a big deal). So you will have to create the AJAX requests manually, handle the response, load the response data into your objects, and basically maintain all the communication workflow between your client app and your API. The advantage is that you will be 100% in control, but with a little more effort, as described here by Robin Ward. You will still be able to use the routing API and most great features that make Ember what it is.

So the question of when and where to use each of these types really depends on what architecture you have on your backend and what level of flexibility you have around that.

This is not something that can have a definite answer for everybody, but can be dealt with by answering a few questions that will asses the viability of using Ember-Data (think on the long run).

• Does my API return JSON in the same format defined by Ember conventions?
• If that's true only partially, can my team and I simply define mappings on a model basis to have everything conforming to conventions?
• If not, can I change my backend API to conform to these conventions?
• If not, where can I find an adapter that is specific for my backend technology?
• I can't find one; would it be feasible to write my own adapter?

After answering these questions, take into account the development iterations and life cycle; think of what would take to maintain it with either approach in the long run; and also consider what path other people in the community have taken when deciding their architecture and/or development strategy.

In the end of the day, you have to understand what these objects bring in terms of features and whether or not you will need them in order to build your application. IMHO, Ember-Data is the way to go for most cases and it can only get better as we approach to (possibly RC3 and then) Ember 1.0 final, which is likely to include Ember-Data as part of the package.

I hope this can help