我正在做一个相当复杂的 emberjs 应用程序，并将其绑定到 API 的后端。
API 调用通常不绑定到任何特定模型，但可能会在响应的不同部分返回各种类型的对象，例如，对事件 API 的调用将返回事件，但也会返回媒体资产和参与这些事件的个人。
我刚刚开始这个项目，我想获得一些专家指导，了解如何最好地分离关注点以拥有一个干净的可维护代码库。
我接近这个的方式是：
- 模型：本质上是处理带有字段和其他计算属性的记录。但是，模型不负责提出请求。
- 例如个人、事件、图片、帖子等。
- 商店：它们本质上是缓存。例如， an
eventStore会将迄今为止从服务器接收到的所有事件（可能来自不同的请求）存储在一个数组中，并且还存储在由 . 索引的事件的哈希中id。- 例如个人商店、事件商店等。
- 控制器：它们与一组相关的 API 调用相关联，例如 eventsController 将负责获取事件或特定事件，或创建新事件等。它们会将响应“路由”到不同的响应以
stores供以后检索。一旦发送到商店，他们就不会保留回复。- 例如 eventsController、userSearchController 等。
- 视图：它们与特定视图相关联。一般来说，我的应用程序可能在不同的地方有几个视图，例如
latestEventsView在仪表板上，除了有一个单独的事件页面。 - 模板：就是它们。
很多时候，我的模板需要直接绑定到商店（例如peopleView，想要在一个列表中列出 individualStore 中的所有个人，按某种顺序排序）。
有时，它们绑定到计算属性
alivePeople: function () { ... }.property('App.individualStore.content.@each'),
视图中“选择”的各种过滤和排序选项应该从商店返回不同的列表。您可以在什么是正确的 emberjs 在各种过滤选项之间切换的方式中看到我的最后一个问题？
谁应该做这个过滤，视图本身还是商店？
这种跨层的绑定可以吗，还是有代码味道？关注点分离是好的，还是我错过了什么？控制器不应该在这里做更多的事情吗？我的视图应该直接绑定到商店吗？
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 的环境发生了很大的变化，新的指南也有了很大的改进。EmberJS 已经提出了约定（如 Rails），并且 MVC 现在定义得更好。
任何仍然困惑的人都应该阅读所有指南，并观看一些视频： Seattle Ember.js Meetup
目前，我正在将我的应用程序升级到Ember.js 1.0.0-pre2.