10

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

4

6 回答 6

16

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

仅服务器端路由

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

仅客户端路由

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

混合方法

混合方法是 Backbone 路由器大放异彩的地方。您使用服务器端路由来提供视图/模板，然后使用 Backbone 的路由增强它们。这里有几个例子：

  1. 具有内联编辑器的用户配置文件页面。路由可能是：/users/me#mode=edit，其中/users/me是服务器提供的典型路由，并且#mode=edit是将视图更改为“编辑”模式的主干路由，用户可以在其中编辑其个人资料信息。
  2. 突出显示日期的日历。路线可能是：/calendars/work#date=today. 这是一个服务器端路由无法做到的示例：突出显示日历的特定单元格（即today）。

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

于 2013-02-18T22:36:30.847 回答
4

好处

  • 快，通常你只需要加载页面的一部分
  • 令人难忘，历史被保留一页，你可以控制什么进入历史，什么不是
  • 有条理，当您构建客户端应用程序时，最好在客户端拥有所有必要的逻辑，包括调度程序（路由器）等重要组件
  • 很容易做到，实现几乎与服务器端相同，您指定路由和处理程序，然后在锚点 href attr 中链接。

例外情况

  • 当您想要提交包含文件的表单时，只使用操作 url 来处理多部分数据会更容易

只是我的 2 美分

编辑：在令人难忘的行中删除了“作为服务器端”。

于 2013-02-13T13:53:10.617 回答
2

这完全是一个偏好问题。它基本上是询问何时执行 AJAX 请求而不是完整请求的另一个版本。您可以将 Backbone 完全用于单页应用程序的路由，然后让后端通过 API 代表模型的纯表示。如果追求 HTML5 -> 移动类型的解决方案，这将特别有用。我建议您根据您和您的同事的技能组合开始采用更温和的方法。

最好的第一步通常是确保使用诸如骨干路由器之类的东西来表示与主要应用程序目的一致的可寻址前端状态更改。如果前端正在执行诸如显示从 AJAX 请求创建的详细视图之类的操作，那么与其通过附加到某个 UI 元素的事件处理程序来实现它，您应该使用 UI 的哈希段和前端路由来实现它元素链接到。因此，例如 UI 元素将只是一个链接到类似的东西/#/item/45，然后路由器会选择它并运行附加到模式的处理程序，例如/#/item/{itemId}. 这更好地代表了状态，并为利用浏览器历史记录和创建以干净方式使用现有前端代码的链接打开了大门。

从这里开始后，您可以根据需要越来越多地实现路由器。

于 2013-02-08T19:41:13.803 回答
2

为什么我会使用它：

  • 更简洁的 UI 应用程序代码。集中处理问题的方法。这对于复杂的 UI 应用程序起着重要作用。

接下来的两项与客户端路由有些相关（虽然不是直接相关）：

  • Ajax 请求不需要取回整个页面（尽管仍然可以）。
  • Ajax 请求可以使用紧凑的数据格式（例如 JSON），这使得请求处理更快。

为什么我不会使用它：

  • SEO变得有点难以完成。客户端路由主要映射到客户端功能，而不是 URL。这意味着，搜索引擎将看到不会指向不同内容页面的链接。这显然是不希望的。在某种程度上，您可以尝试使用站点地图来克服它。
  • 作为对上述问题的另一个克服，网站开发人员有时必须在客户端和服务器端支持相同的 URL 结构（路由）。这是为了达到同样的目的而付出更多的努力。在我看来，这是一个错误，因为这些网站一开始被认为是公开的，但被设计为私有的。在大多数情况下，此类应用程序的设计可能只考虑 Ajax，而不考虑客户端路由。

结论：

话虽如此，在我看来，客户端路由对于不需要爬网的富 UI 应用程序最有意义（主要是因为它们受密码保护）。

例如电子邮件、聊天、企业应用程序、游戏、其他自定义应用程序。

另一方面，您可能已经注意到，旨在被抓取的网站不使用客户端路由。

例如博客、公共网站、维基页面等。

值得一提的是，您可以在同一个应用程序中混合使用这两种方法，只要它具有属于上述不同类别的不同部分即可。

于 2013-02-18T15:52:59.020 回答
1

对于单页应用程序，浏览器不会在每次用户进行操作时重绘整个页面，而是由 Javascript 生成内容并注入到页面中。客户端路由在地址栏中维护状态，以便用户可以直接返回到该状态，这使得这些状态可收藏、可共享等。

您仍然需要进行服务器端路由。从骨干文档：

例如，如果您有 /documents/100 的路由，如果浏览器直接访问该 URL，则您的 Web 服务器必须能够提供该页面。

于 2013-02-17T00:00:15.330 回答
1

您将进行服务器和客户端路由。

从客户端到服务器的请求仍然需要在服务器上路由。从您的服务器的角度来看，路由仍然是为 Ajax 请求完成的。

客户端路由器用于路由#links到您的主干应用程序。因此，当有人单击#链接时，您的路由器将拾取它并采取行动 - 很可能会触发适当的事件。

路由器非常不同，现在我想不出在任何情况下你会使用一个而不是另一个。

于 2013-02-18T10:19:53.527 回答