The Ember-data of Emberjs

Emberjs's Ember-data is written in the front.

Recently busy, new job to learn a lot of new technology stack, and give yourself a lot of excuses to not insist on blogging. Often ironically, more of the rest of the time is not used and more is wasted, perhaps this is the youth bar, squander it, this is not what I want, since this, I will continue to write, adhere to the blog to do a good job, to win the Top 100 blog, I would like to remember.

Late May 7, 2015, next to the computer.

Article index

JS front-end frame of the Ember.js series

What is Ember-data?

For simple applications, you can use jquery to load JSON data from the server and use these JSON data objects as models.

However, using a model library to manage queries, change, and save changes back to the server can greatly simplify the code, while also improving the robustness and performance of the application, resulting in the Ember-data data model.

Ember-data does not require any configuration, it can implement the RESTful JSON APIs provided by the server to load and save records and their management relationships, all of which follow specific conventions.

If the Ember.js application needs to be integrated with existing, non-conforming JSON APIs, Ember-data is well designed to use the data returned by the server with a simple configuration.

The Ember-data also works with streaming APIs such as Socket.io, Firebase, or websockets. By creating a socket connection to the server, these changes are pushed to the local repository (Store) when the records change.

Core Concept Warehouse

A warehouse is a central warehouse where records are applied. You can think of the repository as the cache of all the data that is applied. Both the application's controller and routing can access the shared warehouse, and when they need to display or modify a record, they first need to access the repository.

　　DS.Storeis automatically created, and the instance is shared by all objects in the app.

You can use this instance to get records, create new records, and so on. For example, you need to model find a record of the type App.Person , ID, in the hook of the route 1 :

App.indexroute = Ember.Route.extend ({  model:function () {    return this.store.find (' person ', 1);  }});

Model

A model is a class that defines the properties and behavior of the data that needs to be presented to the user. The data that any user expects to see when they leave the app and then go back to the app should be represented by the model.

For example, if you are writing a web app that can order a restaurant, the app should contain models such as order, LineItem, and MenuItem.

Getting an order is very easy:

1	This.store.find (' order ');

The model defines the type of data that the server provides. For example, the person model might contain a property of a string type named FirstName, and a property of a date type named birthday.

1 2 3 4

App.person = DS. Model.extend ({ FirstName:DS.attr (' string '), Birthday:DS.attr (' Date ') });

The model also declares its relationship to other objects. For example, an order can have many lineitems, and a lineitem can belong to a specific order.

1 2 3 4 5 6 7

App.order = DS. Model.extend ({ LineItems:DS.hasMany (' LineItem ') }); App.lineitem = DS. Model.extend ({ Order:DS.belongsTo (' order ') });

The model itself has no data, and the model defines only the properties and behaviors that its instances have, which are called Records

Recording

A record is an instance of a model that contains data that is loaded from the server side. The app itself can also create new records and save new records to the server side.

Records are uniquely identified by the following two properties:

1. Model type
2. A globally unique ID

For example, if you are writing an app for contact management, there is a model named person. In the application, there may be a record with a type of person,id of 1 or Steve-buscemi.

1	This.store.find (' person ', 1); //+ = {id:1, name: ' Steve-buscemi '}

The ID is usually set when the record is first created on the server side and, of course, the ID can be generated on the client.

Adapter

An adapter is an object that understands the backend of a particular server and is primarily responsible for translating requests and changes to records into the correct calls to the server-side requests.

For example, if an app needs a person record with an ID of 1, how does ember data load the object? Is it through HTTP, or WebSocket? If it is through HTTP, then the URL will be/PERSON/1, or/resources/people/1 it?

The adapter is responsible for handling all similar problems. Whenever an app needs to fetch a record from the warehouse that is not cached, the app accesses the adapter to get the record. If a record is changed and the change is ready to be saved, the warehouse passes the record to the adapter, which is then the responsibility of the adapter to send the data to the server side and confirm that the save was successful.

Serialization of

　　serialization is primarily responsible for translating native JSON data returned from the server side into a record object.

The JSON API may represent attributes, association relationships in different ways. For example, some property names might take a 驼峰式 naming convention, while others use a 下划线隔离 naming convention. The Representation of association relationships is a variety of things: they can be an array of IDs, an inline collection of objects, or a foreign key.

When the adapter obtains data from the server side to a particular record, it gives the data to the serialized object, which in turn transforms the data into the format expected by Ember data.

Most people need to use serialization to complete the conversion of JSON data, because Ember data handles it as a non-transparent object, which may be stored as binary data or arraybuffer.

Automated caching

The warehouse automatically caches the records. If a record is already loaded, the same object instance is returned when it is accessed again. This greatly reduces the round-trip communication with the server side, allowing the application to render the desired UI to the user faster.

For example, when an app obtains a person record with ID 1 for the first time from the warehouse, the object's data is fetched from the server side.

However, when the app needs a person record with ID 1 again, the warehouse will find that the record has been acquired and the record is cached. The repository will no longer send requests to the server to fetch the recorded data, but instead directly return the records that were acquired and constructed at the first time. This feature makes it possible to return the same record object regardless of how many times the record is requested, which is also known as Identity map(identifier mapping).

Using identifier mapping is important because it ensures that changes to one record on one UI are automatically propagated to the UI for other UI usage to that record. At the same time this means that you do not have to manually keep the object in sync, just use the ID to get the record that the app has acquired.

Introduction to Architecture

When an application obtains a record from the warehouse for the first time, the warehouse discovers that the local cache does not have a copy of the requested record, and requests are made to the adapter. The adapter will fetch records from the persistence layer, and typically, the persistence layer is an HTTP service through which a JSON representation of the record can be obtained.

As shown, the adapter sometimes cannot return the requested record immediately. The adapter must then initiate an asynchronous request to the server before it can be created by the returned data after the request has completed loading.

Because of this asynchrony, the warehouse immediately returns a promise (Promise) from the Find () method. In addition, all requests that require the warehouse to interact with the adapter will return a commitment.

Once the server-side request returns the JSON data for the requested record, the adapter fulfills the commitment and passes the JSON to the warehouse.

The warehouse then acquires the JSON and uses the JSON data to complete the initialization of the records and uses the newly loaded records to fulfill the commitments that have been returned to the application.

Here's what happens when the warehouse has cached the requested records.

In this case, the warehouse has cached the requested record, but it will also return a promise, except that the promise will be fulfilled immediately using the cached record. At this point, because the warehouse already has a copy, there is no need to request the adapter (no interaction with the server).

The Ember-data of Emberjs