ruby-on-rails - Rails 3.2 JS-heavy 应用程序的设计模式

Question

我正在开发一个新的 Rails 3.2 公司管理应用程序，它严重依赖 JSON 数据(自动完成结果、日历事件、任务、动态表单操作等)。后端系统已经相当稳固，所以我们正在对 UI 部分进行投资，我们希望使其更像 webapp，反射(reflect)其他“胖客户端”应用程序的行为，例如来自 Google 的那些。为了实现这个目标，最好的设计模式是什么:使用诸如 Backbone.js 之类的 MVC JS 框架，从而将大部分数据操作委托(delegate)给 UI 并与我们的 JSON api 接口(interface)，或者使用远程 JS(即js.erb 模板)，它允许更多地使用 Ruby 代码？

我们已经在某些 View 中非常粗略地使用 Backbone.js，但似乎前一种方法使用了大量的开发人员资源，因为 JS 更难编码，而且我们有额外的负担在 UI 上镜像一些模型代码，同时作为一个对最终用户 react 更快。后一种方法允许以牺牲响应时间为代价获得更精简的 View 代码，总而言之，感觉不太对劲，但它确实可以更快地开发和更灵活。

请记住，我们是一个拥有丰富 Rails 经验的小团队，在 JS/Coffeescript/Backbone.js 方面没有那么多经验，而且我们的截止日期很近，你会选择哪种方法？我对此感到不知所措的原因是我们公司以我们的代码质量和对现代设计模式的坚持而自豪，所以我不禁认为，尽管有其优点，但使用远程 JS 感觉就像“糟糕的捷径”，所以我非常感谢你们的意见。也许我只是有偏见。

Answer 1

好吧，我不能为你做决定，这主要取决于截止日期有多近，但我个人更喜欢 Backbone.js 方法。

如果我不得不争论，我可以说您将拥有一个静态且可缓存的 JS 脚本和轻量级 AJAX 请求(仅 JSON)，而使用其他方法您将下载更重且不可缓存的脚本。

但最重要的是，我相信 Backbone 方式是让您的代码组织和可维护的最佳方法。

Coffeescript 很棒，而且学习速度非常快。它简化了很多 JS 语法并使它变得有趣。值得一试。学习了 3000 万。

Backbone.js 很棒而且学习速度很快。使用这种方法将允许您依赖事件，这比我们可以做的要干净得多。

感谢 Assets 管道，您可以将 View /模型/路由器类拆分为单独的文件，这非常好。

感谢coffeescript，您可以使用非常简洁的语法编写您的主干对象:

class @MyView extends Backbone.View
  events:
    'click obj': 'handler'
  [...]

有了这个，我在我的项目中添加了一点 @module帮助将我的对象组织到命名空间中。

但是，您需要一些时间才能找到好的文件组织。

您可以从 gem rails-backbone 开始并有一些类似于 rails 的生成器。我个人不喜欢它，但我认为这是一个好的开始。它包括一个 Backbone.sync适应rails的功能。

编辑

这里有一些关于 @module 的详细信息 helper 。我将其包含在 application.js.coffee 中(不要忘记 require_self ):

@module = (names, fn) ->
  names = names.split '.' if typeof names is 'string'
  space = @[names.shift()] ||= {}
  space.module ||= @module
  if names.length
    space.module names, fn
  else
    fn.call space

在我的类文件中:

@module 'MyProject.Model', ->
  class @MyModel extends Backbone.Model
    [...]

(注意 @ 是 this. 的 CoffeeScript 快捷方式。)

助手创建对象 MyProject和 MyProject.Model如果需要(如果为 null)并使用 this 执行给定的函数绑定(bind)MyProject.Model .因此，您可以从根命名空间( document )访问您的模型:

m = new MyProject.Model.MyModel

您还可以覆盖助手:

@module 'MyProject', ->
  @module 'Model', ->
    [...]

我使用以下命名空间层次结构

MyProject
  Model
  View
  Router
  Runtime (to store all runtimes objects and don't pollute the root namespace, easier for debug)