Ember 对象和 Ember Data 对象之间的区别

Question

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

Answer 1

注意：这是相当长的，有偏见的，代表我自己对此事的看法。可能不是答案。

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

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

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

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

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

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

因此，何时何地使用这些类型的问题实际上取决于您在后端拥有什么样的架构以及您在这方面的灵活性水平。

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

• 我的 API 是否以 Ember conventions 定义的相同格式返回 JSON？
• 如果这只是部分正确，我和我的团队是否可以在模型基础上简单地定义 mappings 以使所有内容都符合约定？
• 如果不是，我可以更改我的后端 API 以符合这些约定吗？
• 如果没有，我在哪里可以找到专门针对我的后端技术的适配器？
• 我找不到；自己写适配器可行吗？

回答完这些问题后，再考虑开发迭代和生命周期；想想从长远来看，用任何一种方法来维护它需要什么；并考虑otherpeople 在社区中决定其架构和/或开发策略时所采取的路径。

归根结底，您必须了解这些对象在功能方面带来了什么，以及您是否需要它们来构建您的应用程序。恕我直言，Ember-Data 是大多数情况下要走的路，它只会在我们接近（可能是 RC3，然后是）Ember 1.0 最终版时变得更好，它可能会将 Ember-Data 作为软件包的一部分。

希望对你有帮助