EmberJS:在相当复杂的应用程序中,对模型,商店,控制器,视图的关注点有很好的分离？

Question

我正在做一个相当复杂的emberjs应用程序,并将它绑定到API的后端.

API调用通常不依赖于任何特定模型,但可以在响应的不同部分返回各种类型的对象,例如,对事件API的调用将返回事件,但也返回参与这些事件的媒体资产和个人.

我刚刚开始介绍这个项目,我想获得一些关于如何最好地分离问题以获得干净的可维护代码库的专家指导.

我接近这个的方式是:

模型:基本上处理包含其字段和其他计算属性的记录.但是,模型不负责提出请求.
- 例如个人,事件,图片,帖子等
商店:它们本质上是缓存.例如,a eventStore将存储从服务器到目前为止(从可能不同的请求)接收的所有事件,并且还存储在索引的事件的散列中id.
- 例如individualStore,eventStore等.
控制器:它们与一组相关的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

我想到的一些与我的设计有关的问题是:

更新2013年1月9日

是的,它已经很长了,但这个问题最近得到了很多观点,这就是为什么我想编辑它以便人们可以理解.

自从这个问题陷入困境以来,Ember的风景发生了很大的变化,新的指南得到了很大改善.EmberJS提出了各种约定(如Rails),MVC现在定义得更好.

任何人仍然困惑应阅读所有指南,并观看一些视频: 西雅图Ember.js Meetup

目前,我正在升级我的应用程序Ember.js 1.0.0-pre2.

Answer 1

您应该从州的角度来考虑您的应用程序。看看这个
最初，只需要一个路由和一个模板来描述某些内容并最终将其显示在浏览器中，这就是 Emberjs 的新 API 试图强制执行的内容。当您的需求变得更加详细时，您可以添加视图、控制器或对象。每一个都满足特定的需求。
如果您需要处理任何浏览器事件或包装您用于动画、样式设计的任何第 3 方 javascript 库，请考虑使用视图。
如果您需要捕获特定于域的信息（很可能模仿后端信息），请考虑使用对象。
控制器仅仅是域对象的代理，并且可以封装不一定与该对象相关的逻辑。

这就是全部内容了。如果您了解如何根据状态来设计应用程序，那么剩下的部分就会落入正确的位置，只要您使用最新的 api，执行我之前提到的规则。