Backbone.js 与非 RESTful 应用程序？（Backbone.js 是否适合我当前的项目？）答案

【问题标题】：Backbone.js with non RESTful app? (is Backbone.js right for my current project?)Backbone.js 与非 RESTful 应用程序？（Backbone.js 是否适合我当前的项目？）
【发布时间】：2011-08-31 00:18:17
【问题描述】：

我正在尝试确定 Backbone.js 是否适合我当前的项目：一个可视化应用程序。

我有几个问题：

1) 状态/路由？

由于这不是典型的 RESTful 应用程序，而是具有各种图表类型和这些图表设置的可视化应用程序，我如何维护 URL 中的状态？假设我的 areaChart 模型有许多这样的默认值：

AreaChartModel = Backbone.Model.extend({
    defaults: {
        selectedCountries: [],
        year: 1970,
        stacked: false
    },
    initialize: function(){
        [...]
    }
});

在更新模型时，我想序列化其中一些属性，以便为特定状态添加书签：chartApp.html#!year=1970&stacked=false 等。

反之亦然，当使用此状态初始化应用程序时，我如何“取消参数” url 状态并设置模型？我可以使用 Backbone 的内部路由吗？

2) 控制器和耦合器？

Backbone 似乎有一个非常紧密的视图模型耦合？这真的是我应该如何将我的 areaChartView 绑定到模型吗？

AreaChartView = Backbone.View.extend({
    initialize: function(){
        areaChartModel.bind("change:year", this.render);
    }
});

这通常不是控制器的角色吗？

3) 延续：模型与控制器？

鉴于这种情况：

“侧边栏”的更改应触发一系列功能：
1) “应加载当前选择的新数据”
2) “基于此数据，应更新可视化视图中的比例”
3）“应呈现可视化视图”

我应该将这些函数放置在哪里？如何在模型中创建一个在状态稳定时触发的事件？（即当所有函数都被调用并且是时候设置视图状态时？）

【问题讨论】：

标签： javascript model-view-controller javascript-framework backbone.js

【解决方案1】：

1) 我会使用“:params”和“*splats”, read more 尽可能多地使用 Backbone.js 原生路由。您可以将所有查询放入 Backbone.js 路由中，但我个人会牺牲某些东西来支持直观的 UI 按钮

例如我将默认设置为线栏，您不能使用 URL 预设它，但更改为堆叠图只需单击一个按钮。

我可能会一直使用 ?和 & 在我的网址中。稍后我可能会回到这一点，因为它很有趣。

2) 您的示例很好，您只需要记住 Backbone.js MVC 术语与传统 MVC 无关。

主干视图本质上是传统 MVC 中的控制器。骨干控制器只是在框架内进行路由的一种方式。您与 Backbone.js 一起使用的模板引擎是传统的 MVC 视图。

3) 还在写

【讨论】：

非常感谢您的意见。这真的很清楚：“Backbone Views 本质上是传统 MVC 中的控制器。与 Backbone.js 一起使用的模板引擎是传统的 MVC 视图。”现在我只是在努力解决 #3 - 模型更新时应该按顺序调用的所有函数的放置位置。
现在大多数人认为控制器的主要功能是路由器，因为服务器端 MVC 包试图将 MVC 融入不同的范例。由于控制器总是重新渲染整个视图，因此服务器上不需要粘合事件和视图的任务。在传统的客户端 MVC 中，控制器负责响应事件并仅更新需要它的视图。但是，路由确实非常适合页面的顶级控制器角色（因此它可以将状态保存为书签）

【解决方案2】：

关于问题 #3，我将为滑块创建一个 Model 和一个 View。

然后我会将模型上change 事件的触发与更新图形视图的视图中的某个函数相关联（例如更改比例）。比如：

var Slider = Backbone.Model.extend({})

var SliderView = Backbone.View.extend({
    initialize: function() {
        this.model.bind('change', this.render);
    }

    render: function() {
        // load data, change scales, etc.
    }
});

var slider = new Slider();
var slider_view = new SliderView({ model: slider });

也许一个好主意是将绑定放在父视图中，然后分派给子视图，协调它们的工作。

【讨论】：

【解决方案3】：

坐下来考虑一下保持整个状态是否是个好主意？拥有基于 url 的状态管理的主要动机是能够支持基于浏览器的导航按钮并能够为页面添加书签。在可视化应用程序中，您的数据可能每时每刻都在变化。这不是您想要保留在您的应用程序网址中的内容。当用户为您的应用程序添加书签并在三天后返回时，您是否真的想要这样 - 他看到三天前数据的可视化？对于您的场景，假设我没有误解您的要求，我建议您将数据状态保留在模型本身中。

还有关于视图与模型数据的同步，是的，您可以自己编写所有绑定逻辑。在这种情况下，您的 View 类将负责在第一次渲染时设置绑定。并且在后续调用 render 时（可以调用以响应模型中的任何更改事件），将刷新可视化所在的 DOM/canvas。

也许您应该期待一个数据同步插件，它可以为您处理大部分样板文件。 This page 列出了一些可用的数据绑定扩展。 Orchestrator 是我一直在研究的另一个解决方案，在这方面可能会有所帮助。

【讨论】：