设计模式的Rails 3.2 JS沉重的应用程序

Question

我正在研究一个新的rails 3.2公司管理应用程序，它严重依赖于JSON数据（自动完成结果，日历事件，任务，动态表单操作等）。后端系统已经非常稳固，因此我们正在投资UI部分，我们希望使其更像Web应用，以反映其他“胖客户端”应用程序的行为，例如来自Google的应用程序。为了实现这个目标，最好的设计模式是什么：使用Backbone.js这样的MVC JS框架，从而将大量的数据操作委托给用户界面，并与我们的JSON API进行交互，或者与远程JS（即js.erb模板），它允许更多地使用Ruby代码？

我们已经使用Backbone.js的非常粗略的一些看法，但似乎前一种方法使用了大量的开发者资源，因为JS是很难的代码，我们有镜像对UI的一些型号代码的额外负担，同时对最终用户有更多的响应。后一种方法允许以牺牲响应时间为代价来减少视图代码，总之，感觉不太好，但开发速度肯定更快，而且更灵活。请记住，我们是一个拥有大量Rails经验的小团队，而不是JS/Coffeescript/Backbone.js中的那么多，而且我们有一个紧迫的截止日期，您会选择哪种方法？之所以我在这方面亏本，是因为我们公司以我们的代码质量和遵守现代设计模式为荣，所以我不禁想到，尽管它的优点是，使用远程JS感觉像是一个'坏捷径'，所以我会非常感谢你们的意见。也许我只是有偏见。

Answer 1

嗯，我不能为您决定，主要取决于截止日期有多接近，但我个人喜欢Backbone.js方法。

如果我不得不说，我可以说你会有一个静态和可缓存的JS脚本和轻的AJAX请求（只有JSON），而与另一种方法，你会有更重和不可缓存的脚本下载。

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

1. Coffeescript非常好，学起来非常快。它简化了很多JS语法并使其变得有趣。这值得尝试。在30mn学习。

2. Backbone.js非常好，而且学起来很快。使用这种方法将允许您依赖事件，这比我们无法做到的事情要干净得多。

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

   由于CoffeeScript中你可以用一个非常清晰的语法一样，写你的骨干对象：

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

   有了，我在我的项目加入少许@module帮手来组织我的对象到命名空间。

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

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

编辑

这里对@module帮手一些细节。我包括这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绑定到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)