12

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

4

1 回答 1

31

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

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

Ember-DataDS.Model大量扩展了这些功能，Object以便在（大多数情况下）RESTful 环境中处理后端数据时提供更多有意义的功能。很像 ORM 支持的对象（例如：.NET 的 EntityFramework 或 Ruby 的 ActiveRecord），它提供了一组特性，因此该类型的对象DS.Model（它将允许状态管理（DS.Store、、、等）、存储中的和对象的能力（以及随后的后端 API）、关系/关联等。ObjectisDirtyisNewisErrorisNewcommitrollback

如果您使用的是 Ember-Data，则应该使用 type Model，因为它（旨在与商店一起使用，并且）在侧载、关联、复数以及整个 AJAX 请求/响应工作流程中使用模型类型。事实上，使用由 aModel支持的一个优点Store正是这样：让框架通过自己构建对正确 RESTful 资源的 AJAX 请求、管理响应、将 JSON 有效负载侧加载到正确类型的对象，同时向您保证可以在请求/处理/物化数据时使用模型（因此您可以在发生这种情况时转换视图/路由）。

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

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

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

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

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

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

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

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

我希望这可以帮助

于 2013-04-06T17:55:04.190 回答