Before we move on to creation and persistence of the model objects defined in the previous section, we need to understand a very core part of ember-data library, the Store.
DS.Store or simply store, is a central repository that contains all the data of the model objects that were fetched from the server. It is also responsible for managing the life cycle of the instances of DS.Model types. This includes creating instances of DS.Model class, searching, saving, updating, and deleting records to the server.
The instance of DS.Store is automatically created, and is made available as a property to all the components of your application. This happens when the ember-data library is loaded. Normally, an Ember.js application will have only one instance of DS.Store, which is shared across the application.
The store also acts like an in-memory cache for your application. If a record that was just fetched from the server is asked to be fetched again, then the store will return the same object that is already present in the cache that was fetched recently, rather than making another an HTTP call to the server to fetch the record again. This minimizes the network calls made to the server, and hence renders the template that displays the record quickly. This behavior, in which the store always returns the same object when the search parameters provided to it are same, is known as an identity map, and hence DS.Store is also referred as an identity map.
Let's see what happens when you send a request to fetch a record to be displayed in your template:
This depicts the flow when your application asks the store to fetch a record from the server
When your application requests the store to find a record for a given ID or a condition, the store will first check whether or not the record is already present in its cache. If it's not present, then the store will ask the adapter to fetch the record for it.
Adapter in ember-data is an object that actually communicates with the backend server. It knows about how and what calls it needs to make to the server to fetch the data. For example, if the store asks the REST adapter to fetch a book with the ID 2 for it, a REST adapter shall follow the REST conventions while making the call to the server. It shall translate that request into an HTTP GET call with URL /books/2 to the server. When an adapter in an asynchronous world is not able to return the result to the store immediately, so they instead of returning the actual object the adapter immediately returns a promise to the store which is resolved once the adapter receives the actual JSON data from the server. Similar to this is when the application asks the store for a record that is not present in the store. The store returns a promise to the application, which is resolved when the adapter sends the data received from the server to the store. On receiving the JSON data from the adapter, the store initializes the model object from the data returned, and the template that is bound to the record is updated with the latest data fetched from the server.
On the other hand, if the store receives a request for a record that is present in its cache, the store resolves the promise immediately, and presents the retrieved object to the application.