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

时间:2012-04-12 06:27:51

标签: model-view-controller store ember.js separation-of-concerns

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

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

我刚刚开始使用该项目,并且我希望获得一些专家指导,以便最好地将问题分开,以便拥有一个干净的可维护代码库。

我接近这个的方式是:

  • 模型:基本上处理包含其字段和其他计算属性的记录。但是,模型不负责提出请求。
    • e.g。个人,事件,图片,发布等。
  • 商店:它们本质上是缓存。例如,eventStore将存储从服务器到目前为止(可能来自不同请求)的所有事件,并且还存储由id索引的事件的哈希。
    • e.g。 individualStore,eventStore等。
  • 控制器:它们与一组相关的API调用相关联,例如: eventsController将负责获取事件或特定事件,或创建新事件等。他们会将响应“路由”到不同的stores以供以后检索。一旦将响应发送到商店,它们就不会保留响应。
    • e.g。 eventsController,userSearchController等。
  • 观看次数:它们与特定视图相关联。一般来说,我的应用程序可能在不同的地方有几个视图,例如除了具有单独的活动页面之外,仪表板上的latestEventsView
  • 模板:就是它们。

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

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

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/videoshttp://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

3 个答案:

答案 0 :(得分:4)

  • 您应该根据州来考虑您的申请。请查看this

  • 最初,只需要描述路线和模板 一些东西,最后在浏览器中显示,这就是新的东西 Emberjs的API试图强制执行。随着您的要求越来越多 详细说明你可以投入一个视图,一个控制器或一个对象。每 虽然满足了特定需求。

  • 如果您需要处理任何浏览器事件或换行,请考虑一个视图 任何你用于动画,造型的第三方javascript lib。

  • 如果您需要捕获特定于域的信息,请考虑使用对象 信息,很可能模仿后端信息。

  • 控制器只是域对象的代理,可以封装与对象无关的逻辑。

这就是它的全部内容。如果你学习如何根据状态设计你的应用程序,其余的将落在正确的位置,只要你使用最新的api,执行我之前提到的规则。

答案 1 :(得分:3)

自从使用新的路由器实现发布Ember 1.0.0-pre4以来,我看到了两个描述标准化EmberJS应用程序结构的好参考文献。

熟悉Rails的人会觉得它很熟悉。

https://github.com/trek/ember-todos-with-build-tools-tests-and-other-modern-conveniences

http://reefpoints.dockyard.com/ember/2013/01/07/building-an-ember-app-with-rails-api-part-1.html

https://github.com/emberjs/ember-rails处的ember-rails项目包括一个Rails生成器,用于创建EmberJS应用程序目录结构,该结构与上面两个链接中描述的结构基本相同。

EmberJS指南现在也描述了新的路由结构。 http://emberjs.com/guides/

更新2013年8月21日

如果您使用的是Rails,那么ember-rails gem非常棒。我用它取得了很大的成功。 在ember社区中有两项努力来协助提供标准化的ember应用程序布局。显然他们将合并,但现在退房:

https://github.com/rpflorence/ember-tools

https://github.com/stefanpenner/ember-app-kit

答案 2 :(得分:0)

另请参阅此http://addyosmani.com/largescalejavascript/这不是特别关于EmberJs,但它是一篇很棒的文章,让您了解如何编写大规模的JavaScript应用程序。