Ember对象和Ember数据之间的差异

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.Model可以通过数据存储(DS.Store)管理该类型()的对象,并超出已存在的功能.一个Object它将允许状态管理(isDirty,isNew,isError,isNew,等等),能够与commit和rollback与对象在存储(并且随后将后端API),关系/协会等

如果您正在使用Ember-Data,则应使用该类型Model,因为它(旨在与商店一起使用,并且)在侧载,关联,复数和整个AJAX请求/响应工作流中使用模型类型.实际上,使用a Model支持的优势之一Store就是:让框架通过自己构建正确的RESTful资源的AJAX请求,管理响应,将JSON有效负载侧载到一个正确类型的对象,同时给出一个承诺,即您可以在请求/处理/实现数据时使用该模型(这样您就可以在发生这种情况时转换视图/路径).

它还为商店支持的对象本身提供了大量便利功能(例如:),record.deleteRecord(); store.commit()并且在一天结束时,我们可以提高工作效率,并且可以更快地构建应用程序.

有了这个说法,有人批评这种方法,因为大量开发人员通常不喜欢或不喜欢诉诸人们称之为technomagic的东西 ; 换句话说,他们不喜欢使用它,因为他们觉得他们并不是100%控制引擎盖下发生的事情.在我个人看来,同时我可以看到这些人来自哪里,我相信Ember-Data没有帮助我提高工作效率,而且它要求的唯一事情就是我与我的代码和我遵循某些惯例,我很满意.

回到Object,如果您没有使用Ember-Data,您应该使用该Object类型作为模型.这意味着您将手动完成所有这些任务(通常不是很重要).因此,您必须手动创建AJAX请求,处理响应,将响应数据加载到对象中,并基本维护客户端应用程序和API之间的所有通信工作流程.其优点是,你会在控制100%,但有一点更多的精力,如所描述这里由罗宾·沃德.您仍然可以使用路由API以及使Ember成为现实的大多数强大功能.

因此,何时何地使用这些类型的问题实际上取决于您在后端的架构以及您的灵活性.

这不是每个人都可以得到明确答案的东西,但可以通过回答几个问题来处理,这些问题将评估使用Ember-Data的可行性(从长远来看).

• 我的API是否以Ember约定定义的相同格式返回JSON ？
• 如果这只是部分真实的话,我和我的团队能否在模型基础上定义映射以使一切符合约定？
• 如果没有,我可以更改我的后端API以符合这些约定吗？
• 如果没有,我在哪里可以找到特定于我的后端技术的适配器？
• 我找不到一个; 编写自己的适配器是否可行？

在回答这些问题后,考虑开发迭代和生命周期; 想想从长远来看用两种方法来维持它需要什么; 并且还要考虑社区中其他 人在决定他们的架构和/或发展战略时采取了什么样的路径.

在一天结束时,您必须了解这些对象在功能方面带来了什么,以及您是否需要它们来构建应用程序.恕我直言,Ember-Data是大多数情况下的方法,它只能在我们接近(可能是RC3然后)Ember 1.0 final时变得更好,这可能包括Ember-Data作为包的一部分.

我希望这可以提供帮助