ember.js - Ember 对象和 Ember Data 之间的区别

Question

Ember 对象和 Ember Data 中的对象有什么区别？我知道当服务器上有一些数据时我应该使用 Ember Data 模型，但是我应该何时何地使用它们中的任何一个？

Answer 1

注意:这很长，有偏见，代表我对此事的看法。可能不是答案。

型号Object是你可以称之为 Ember 中最“简单”的对象类型。它具有您可能会在现代应用程序中使用的最基本功能，例如计算属性和可观察对象。与运行时相关联，它还允许绑定(bind)、过滤等。我将其称为通用对象，它可以扩展以创建其他类型，也可以与 mixin 结合以进一步增强其使用。它有很多但有限的功能，但我不会称之为后端友好，只是因为我知道 DS.Model及其特点。

Ember-Data DS.Model大量扩展了 Object 中的功能为了提供更多在(大多数情况下)RESTful 环境中处理后端数据时有意义的功能。很像 ORM 支持的对象(例如:.NET 的 EntityFramework 或 Ruby 的 ActiveRecord)，它提供了一组功能，因此可以通过数据存储( DS.Model )管理该类型的对象( DS.Store )，并且超越 Object 中已有的功能它将允许状态管理( isDirty 、 isNew 、 isError 、 isNew 等)，以及 commit 的能力和 rollback和存储中的对象(以及随后的后端 API)、关系/关联等。

如果您完全使用 Ember-Data，则应该使用类型 Model ，因为它(旨在与商店一起使用，并且)在旁加载、关联、复数和整个 AJAX 请求/响应工作流中使用模型类型。事实上，使用 Model 的好处之一由 Store 支持正是这样:让框架通过自行构建对正确 RESTful 资源的 AJAX 请求、管理响应、将 JSON 有效负载旁加载到正确类型的对象中来完成繁重的工作，同时向您 promise 您可以在请求/处理/物化数据时使用该模型(因此您可以在发生这种情况时转换 View /路由)。

它还在商店支持的对象本身(例如:record.deleteRecord(); store.commit())中为您提供了许多方便的功能，最终使我们的工作效率更高，我们可以更快地构建应用程序。

话虽如此，但这种方法受到了批评，因为大量开发人员通常不喜欢或不喜欢诉诸人们所说的技术魔术。换句话说，他们不想使用它，因为他们觉得他们不能 100% 控制引擎盖下发生的事情。在我个人看来，同时我可以看到这些人来自哪里，我相信 Ember-Data 并没有帮助我提高生产力，它唯一要求的返回就是我与我的代码保持一致并且我遵循某些约定，对此我很满意。

返回 Object , 如果你不使用 Ember-Data，你应该使用 Object键入作为您的模型。这意味着您必须手动完成所有这些任务(通常没什么大不了的)。因此，您必须手动创建 AJAX 请求、处理响应、将响应数据加载到您的对象中，并基本上维护客户端应用程序和 API 之间的所有通信工作流。优点是您将获得 100% 的控制权，但需要付出更多努力，如 here 所述通过罗宾·沃德。您仍然可以使用路由 API 和大多数使 Ember 成为现实的强大功能。

因此，何时何地使用这些类型的问题实际上取决于您在后端拥有什么架构以及您对此具有何种程度的灵活性。

这不是每个人都能得到明确答案的问题，但可以通过回答一些问题来解决，这些问题将评估使用 Ember-Data 的可行性(从长远来看)。

我的 API 是否以 Ember conventions 定义的相同格式返回 JSON ?

如果这只是部分正确，我和我的团队可以简单地定义 mappings在模型的基础上让一切都符合惯例？

如果没有，我可以更改我的后端 API 以符合这些约定吗？

如果没有，我在哪里可以找到特定于我的后端技术的适配器？

我找不到；编写我自己的适配器是否可行？

回答完这些问题后，再考虑开发迭代和生命周期；想想从长远来看，用这两种方法维护它需要什么；还要考虑什么路径 other people社区在决定他们的架构和/或开发策略时已经采取了。

归根结底，您必须了解这些对象在功能方面带来了什么，以及您是否需要它们来构建您的应用程序。恕我直言，Ember-Data 是适用于大多数情况的方法，它只会随着我们接近(可能是 RC3，然后是)Ember 1.0 最终版而变得更好，它很可能将 Ember-Data 作为包的一部分包含在内。

我希望这可以帮助