它是基于MVVM模型的开源框架，该框架主要用于创建复杂的多页面应用程序。它的最大功能是，最新功能继续启动并且不会丢弃任何旧功能。
与大多数前端开发框架不同，使用必须遵循严格的JS体系结构，也就是说，它没有很高的灵活性。它可以与任何版本启动的最新版本的工具集成在一起，但是无需过多担心兼容性问题。本文开始开发项目开发。
它是一种用于格式化请求，标准化响应以及有效管理本地数据缓存的强大工具。
它可以与任何类型的后端：或其他后端类型一起使用。
在中间，模型是应用程序提供给用户的基本数据的对象。请注意，尽管该模型具有相同的名称，但它与该方法的概念不同。
不同的应用程序可能具有非常不同的模型，具体取决于他们要解决的问题。或喜欢。
模型通常是持久的，这意味着用户在关闭浏览器窗口时不会期望模型数据丢失。为了确保没有数据丢失，如果用户更改了模型，则需要将模型数据存储在其位置不会丢失。
通常，大多数模型都使用数据库存储数据加载并从服务器中保存。通常，该模型将来回发送到书面HTTP服务器。保存用户的硬盘，或避免编写和托管自己的服务器的托管存储解决方案。
从存储中加载模型后，组件知道如何将模型数据转换为用户可以与之交互的UI。有关组件如何获取模型数据的更多信息，请参见“指定路由的模型”指南。
首先，使用Ember数据可能与JavaScript应用程序有所不同。许多开发人员熟悉从端点上使用Ajax来获取原始JSON数据，这似乎很容易乍一看。渗透到应用程序代码中，这使得很难维护。
借助Ember数据，管理模型在应用程序中很容易增长。
一旦理解它，您就有一种更好的方法来管理应用程序中数据加载的复杂性。这将使代码发展和增长并具有更好的维护。
由于使用了适配器模式，因此配置可用于将其与许多不同类型的背端进行使用。有一个完整的适配器生态系统和几种允许Ember应用程序与不同类型的服务器进行通信的接种。
默认情况下，Ember数据旨在与JSON：API.JSON：API一起使用，是用于构建常规，强和高性能API的正式规范，可允许客户端和服务器通信模型数据。
JavaScript应用程序和服务器的通信方法是标准化的，因此它可以减少正面和后端之间的耦合，并具有更大的更改堆栈的自由度。
如果需要在没有适配器的情况下将Ember.js应用程序与服务器集成（例如，不遵循任何JSON规范的API服务器是手动滚动的），则Ember数据可以配置其工作服务器返回的任何数据。
ember数据还旨在与流服务器一起使用，例如服务器驱动的服务器。您可以在任何更改时打开服务器的套接字并将更改推向ember数据，以便为应用程序提供真实的-Time用户界面这总是保持最新状态。
构建Web应用程序的一种常见方法是提取用户界面元素和数据要紧密耦合。
在项目开发过程中，您可能需要使组件负责获取和存储数据：
然后，草稿列表可以显示在组件模板中，如下所示：
这对组件非常有用。但是，应用程序可能由许多不同的组件组成。在另一个页面上，组件可以显示草稿数量。您可能要将现有代码复制并粘贴到新组件中。
不幸的是，该应用程序现在将向相同信息发送两个单独的请求。冗余数据的采集不仅浪费了带宽，而且还会影响应用程序的感知，而且价格很昂贵，而且这两个值易于同步。我可能已经使用了Web应用程序，其中项目列表与工具栏中的计数器没有同步，这导致了令人沮丧且不一致的体验。
UI和应用程序的网络代码之间也有密切的连接。如果更改URL或JSON的有效负载的格式，则可能会导致难以跟踪所有UI组件。
井设计的坚实原则告诉我们，该对象应承担单一的责任。组件的责任应该是向用户提供模型数据，而不是获得模型。
良好的ember应用程序使用不同的方法。ember数据提供了一个存储库，该存储库在应用程序中的模型中有一个中心内存。路由及其相应的控制器可以询问商店模型，商店负责知道如何获取它们。
这也意味着商店可以在请求同一模型时检测两个不同的组件，因此应用程序只能从服务器中获取数据。存储器可以被视为应用程序模型的一般阅读缓存。路由和相应的控制器可以访问此共享存储；当他们需要显示或修改模型时，他们必须首先询问商店。
Ember数据将存储服务注入了每个路由和控制器，因此您可以通过访问它访问它！
在Ember数据中，每个模型由子类表示。子类模型定义了提供给用户的属性，关系和行为。
模型定义了服务器提供的数据类型。例如，一个人模型可能具有一个名称字符串生日属性和日期属性：
模型还描述了其与其他对象的关系。例如，订单可能具有多个行项目，并且行项目可能属于特定顺序。
模型本身没有数据。他们定义了特定实例的属性，关系和行为，称为记录。
记录是一个包含服务器数据模型的实例。应用还可以创建新记录并将其保存回服务器。
记录通过其模型类型和ID标识。
例如，如果您正在编写联系人管理应用程序，则可能会有一个人模型。该应用程序中的单个记录可能具有类型的人和ID 1或Steve-Buscemi。
第一次保存记录时，服务器通常将ID分配给记录，但也可以在客户端上生成ID。
一个适配器是将对象从ember请求转换（例如，“找到具有1个ID的用户）为服务器。
例如，如果应用程序要求persyid到1，则应如何加载ember？是http还是websock？如果是http，是url还是？
适配器负责回答所有这些问题。当应用程序要求商店询问未准备好的记录时，它将询问适配器。如果更改并保存记录，存储将将记录传输到适配器以将适当的数据发送到适合服务器并确认保存成功。
该适配器可以在不影响Ember应用程序代码的情况下实现API。
商店将自动缓存记录。如果已加载记录，第二个请求将始终返回相同的对象实例。这可以最大程度地减少圆形传输服务器的数量，并允许应用程序尽快将其UI呈现给用户。
例如，当应用程序要求存储提供人员ID的记录时，它将从服务器获取信息。
但是，当申请要求下次请求人员ID时，商店会注意到它已检索并从服务器中调查了信息。。此功能（无论您寻找多少次，始终返回同一记录对象）有时称为身份映射。
使用身份映射非常重要，因为它可以确保UI的一部分进行更改将扩展到UI的其他部分。这也意味着您不必手动保持记录同步，您可以根据您的记录来记录ID要求，而不是担心应用程序的其他部分是否已请求并加载了它。
返回缓存记录的缺点是，自数据的身份映射到商店以来，数据的状态已更改。从存储中返回，Ember数据将自动在后台发布请求。当输入新数据时，将更新更新记录，并且如果自初始渲染以来的记录发生了更改，则新信息将由新信息呈现。
当应用程序是第一次记录时，当您看到它没有本地副本时，它将从适配器请求。适配器将从持久层检索记录。通常，这将从HTTP服务器记录并以JSON格式表示。
如上图所示，适配器不能总是立即返回请求的记录。在这种情况下，适配器必须向服务器发送异步请求，并且只有在请求完成后，它才能使用其备份数据来创建一个记录。
由于这种异步，存储会立即从这种方法中返回承诺。相似，任何存储请求向适配器的任何请求都将返回承诺。
一旦服务器的请求返回请求记录的JSON负载，适配器将使用JSON将承诺解析回商店。
然后，Store使用JSON来初始化JSON数据的记录，并使用新加载的记录分析返回应用程序的承诺。
如果请求存储已记录在其缓存中，该怎么办。
在这种情况下，因为它已经知道记录，所以它将返回一个记录，并且将立即通过记录解决。由于它在本地保存了副本，因此无需向适配器（和服务器）询问副本。