API调用通常不与任何特定的模型相关联,而是可以在响应的不同部分中返回各种类型的对象,例如.对Events API的调用将返回事件,还会返回介入这些事件的媒体资产和个人.

我刚刚开始了这个项目,我想获得一些专家的指导,说明如何最好地将问题分解为具有干净的可维护代码库.

我接近的方式是：

> Models：基本上处理与其字段和其他计算属性的记录.但是,模型不负责提出请求.

>例如个人,事件,图片,邮政等

>商店：它们本质上是高速缓存.例如,eventStore将存储从服务器接收的所有事件(从可能不同的请求)到数组,以及由id索引的事件的哈希.

>例如personalStore,eventStore等

>控制器：它们绑定到一组相关的API调用,例如eventsController将负责提取事件或特定事件,或创建新事件等.他们会将响应“路由”到不同的商店以供以后检索.一旦它被发送到商店,他们就不会保留响应.

>例如eventsController,userSearchController等

视图：它们与特定视图相关.一般来说,我的应用程序可能在不同的地方有几个视图,例如除了具有单独的事件页面之外,Dashboard上还有latestEventsView.
>模板：是什么

通常,我的模板需要直接绑定到商店(例如,peopleView想列出一个列表中的个人商店中的所有个人,按照某种顺序排列).

有时,它们绑定到一个计算的属性

alivePeople: function () { ... }.property('App.individualStore.content.@each'),

视图中“选择”的各种过滤和排序选项应从商店返回不同的列表.你可以在what is the right emberjs way to switch between various filtering options?看到我的最后一个问题

谁应该做这个过滤,视图本身还是商店？

这种跨层的绑定好还是代码嗅？关心的分离是否好,还是我错过了什么？控制员不应该在这里做更多的事情吗？我的意见是否直接绑定到商店？

任何特殊的MVC更适合我的需求？

2012年4月17日更新
我的研究继续进行,特别是从http://vimeo.com/user7276077/videos和http://jzajpt.github.com/2012/01/17/emberjs-app-architecture.html和http://jzajpt.github.com/2012/01/24/emberjs-app-architecture-data.html

我设计的一些问题,我想到的是：

>控制器发出请求(商店或模型或其他应该做的,而不是控制器)
>状态图丢失 – 它们对于视图 – 控制器交互很重要(在某段时间之后,您意识到您的交互不再简单)

这是状态图表的一个很好的例子：https://github.com/DominikGuzei/ember-routing-statechart-example

2013年1月9日更新

是的,已经很久了,但这个问题最近得到了很多的意见,这就是为什么我想编辑它,以便人们可以感觉到.

自从这个问题被掩盖以来,Ember的风景发生了很大变化,而新的guides已经有了很大的改进. EmberJS已经提出了约定(如Rails),现在MVC的定义更为明确.

任何人仍然感到困惑,应该阅读所有的指南,并观看一些视频：
Seattle Ember.js Meetup

目前,我将应用程序升级到Ember.js 1.0.0-pre2.