javascript - 使用 Backbone.js 路由器进行路由而不是使用服务器端代码的原因

Question

我何时以及为什么要使用 Backbone.js 路由器进行路由而不是通过服务器端代码进行路由？有人可以详细说明一下吗，因为这是我第一次在客户端进行路由。

Answer 1

您提出了错误的二分法。现实情况是，永远可能不会出现您使用Backbone 的 路由器代替服务器端解决方案的情况。也就是说，使用客户端路由器(不特别是 Backbone 的路由器)来创建单页应用程序的趋势肯定在增长——例如 Ember.js .以下是您的选择:

仅服务器端路由

这是经典方法，是 Rails 等框架的重要组成部分。这是一种成熟的策略，可以在您的模型、 View 和 Controller 之间划清界限。它肯定不会很快消失，并且有充分的理由:如果你不开发单页应用程序，那很好，大多数人都没有。

仅客户端路由

这就是 Ember 为您提供的东西。您可以在客户端编写所有路由，然后客户端负责更新状态、丢弃旧对象等。这需要模型、 View 和 Controller 的强大 JavaScript 实现才能正常工作。否则你很快就会得到一堆烂意大利面。如果您要这样做，请勿使用 Backbone。 Backbone 的路由器最适用于像状态这样的简单事物。根本没有使用 vanilla Backbone 替换服务器端路由器的干净方法。

混合方法

混合方法是 Backbone 的路由器大放异彩的地方。您使用服务器端路由来提供 View /模板，然后使用 Backbone 的路由来增强它们。下面是一些例子:

1. 具有内嵌编辑器的用户个人资料页面。路由可能是:/users/me#mode=edit，其中 /users/me 是服务器提供的典型路由，#mode=edit 是一个 Backbone 路由，它将 View 更改为“编辑”模式，用户可以在其中编辑他的个人资料信息。
2. 突出显示日期的日历。路线可能是:/calendars/work#date=today。这是您不能使用服务器端路由做的事情的示例:突出显示日历的特定单元格(即，今天)。

除非您打算编写单页应用程序，否则可以肯定地说您不会从使用客户端路由器中获益太多。即使您正在编写单页纸，您也可能不应该指望 Backbone 来完成它。