10

サーバー側のコードを介してルーティングする代わりに、いつ、なぜBackbone.jsルーターをルーティングに使用するのですか？クライアント側でルーティングを行うのは初めてなので、誰かがそれについて詳しく説明してもらえますか。

4

6 に答える 6

16

あなたは誤った二分法を提示しました。現実には、サーバー側のソリューションの代わりにBackbone のルーターを使用する状況はおそらくないでしょう。とは言うものの、 Ember.jsなどの 1 ページ アプリを作成するために、一般的に (特にバックボーンのルーターではなく) クライアント側ルーターを使用する傾向が高まっていることは確かです。オプションは次のとおりです。

サーバー側のルートのみ

これは、Rails のようなフレームワークの大きなコンポーネントである古典的なアプローチです。モデル、ビュー、およびコントローラーの間に非常に明確な線を引くのは、成熟した戦略です。すぐになくなるわけではありませんが、それには正当な理由があります。ほとんどの人が開発していない 1 ページのアプリを開発していない場合には、これは素晴らしいことです。

クライアント側のルートのみ

これは、Ember のようなものが提供するものです。クライアント側ですべてのルートを作成すると、クライアントは状態の更新、古いオブジェクトの破棄などを担当します。これには、モデル、ビュー、およびコントローラーの堅牢な JavaScript 実装が適切に機能する必要があります。そうしないと、すぐに腐ったスパゲッティの山になってしまいます。これを行う場合は、Backbone を使用しないでください。バックボーンのルーターは、状態などの単純なものに最適です。通常のバックボーンを使用してサーバー側のルーターを置き換えるクリーンな方法はありません。

ハイブリッド アプローチ

ハイブリッド アプローチは、Backbone のルーターが活躍する場所です。サーバー側のルートを使用してビュー/テンプレートを提供し、バックボーンのルートでそれらを強化します。そのいくつかの例を次に示します。

  1. インライン エディターがあるユーザー プロファイル ページ。ルートは次のようになります。/users/me#mode=editここで、/users/meはサーバーによって提供される典型的なルート#mode=editであり、ユーザーがプロファイル情報を編集できる「編集」モードにビューを変更するバックボーン ルートです。
  2. 日付を強調するカレンダー。ルートは次のようになります/calendars/work#date=today。サーバー側のルートではできないことの例を次に示します。カレンダーの特定のセル (つまり、today) を強調表示します。

1 ページのアプリを作成する準備が整っていない限り、クライアント側のルーターを使用してもあまりメリットがないと言っても過言ではありません。また、たとえ 1 ページを書いているとしても、それを行うために Backbone に目を向けるべきではないでしょう。

于 2013-02-18T22:36:30.847 に答える
2

なぜ私がそれを使うのか：

  • よりクリーンなUIアプリケーションコード。懸念への集中型アプローチ。これは、複雑なUIアプリケーションにとって大きな役割を果たします。

次の2つの項目は、クライアント側のルーティングにいくらか関連しています（直接ではありません）。

  • Ajaxリクエストは、ページ全体を取り戻す必要はありません（それでも可能ですが）。
  • Ajaxリクエストは、リクエスト処理をさらに高速化するコンパクトな形式のデータ（JSONなど）を使用できます。

なぜ私はそれを使わないのですか：

  • SEOを達成するのは少し難しくなります。クライアント側のルートは、ほとんどの場合、URLではなく、クライアント側の関数にマップされます。つまり、検索エンジンには、さまざまなコンテンツページにつながらないリンクが表示されます。これは明らかに望ましくありません。ある程度、サイトマップを使用してそれを克服しようとすることができます。
  • 上記の問題に対する別の克服策として、Webサイト開発者は、クライアント側とサーバー側の両方で同じURL構造（ルーティング）をサポートする必要がある場合があります。これは、同じ最終結果を達成するためのより多くの努力です。私の意見では、このようなWebサイトは当初は公開されていると考えられていましたが、非公開として設計されていたため、これは間違いです。ほとんどの場合、このようなアプリケーションは、クライアント側のルーティングではなく、Ajaxを念頭に置いて設計されている可能性があります。

結論：

そうは言っても、私の意見では、クライアント側のルーティングは、クロールする必要のないリッチUIアプリケーションに最も適しています（主にパスワードで保護されているため）。

たとえば、電子メール、チャット、エンタープライズアプリケーション、ゲーム、その他のカスタムアプリケーション。

一方、お気づきかもしれませんが、クロールを目的としたWebサイトは、クライアント側のルーティングを使用していません。

例：ブログ、公開Webサイト、Wikiページなど。

言及する価値があるのは、上記のさまざまなカテゴリに分類されるさまざまなセクションがある限り、同じアプリケーションでこれら2つのアプローチを混在させることができるということです。

于 2013-02-18T15:52:59.020 に答える
2

それは完全に好みの問題です。これは基本的に、完全なリクエストではなく AJAX リクエストをいつ実行するかを尋ねる別のバージョンです。単一ページ アプリでのルーティングに Backbone を完全に使用し、API を介してモデルの純粋な表現をバックエンドに表現させることができます。これは、HTML5 -> モバイル タイプのソリューションを追求する場合に特に役立ちます。あなたとあなたの同僚のスキルセットに応じて、より控えめなアプローチから始めることをお勧めします。

通常、最善の最初のステップは、バックボーン ルーターのようなものを使用して、アプリケーションの主な目的に沿ったアドレス指定可能なフロント エンドの状態の変化を表すようにすることです。フロント エンドが、AJAX 要求から作成された詳細ビューを表示するようなことを行っている場合、何らかの UI 要素にアタッチされたイベント ハンドラーを介してそれを実装するのではなく、ハッシュ セグメントを使用して実装し、UI をルーティングするフロント エンドを使用する必要があります。にリンクする要素。たとえば、UI 要素は次のようなものへのリンクで/#/item/45あり、ルーターはそれを取得して、パターンに関連付けられたハンドラーを実行します/#/item/{itemId}。これにより、状態がより適切に表現され、ブラウザーの履歴を活用し、既存のフロント エンド コードをクリーンな方法で使用するリンクを作成するための扉が開かれます。

これを開始した後、必要に応じてルーターを徐々に実装できます。

于 2013-02-08T19:41:13.803 に答える
1

単一ページのアプリケーションの場合、ブラウザーはユーザーがアクションを行うたびにページ全体を再描画するのではなく、代わりに Javascript によってコンテンツが生成され、ページに挿入されます。クライアント側のルートは、ユーザーがその状態に直接戻ることができるように、アドレス バーで状態を維持します。これにより、これらの状態がブックマーク可能、共有可能などになります。

サーバー側のルーティングを行う必要があります。バックボーンのドキュメントから:

たとえば、/documents/100 のルートがある場合、ブラウザーがその URL に直接アクセスした場合、Web サーバーはそのページを提供できる必要があります。

于 2013-02-17T00:00:15.330 に答える
1

サーバー側とクライアント側のルーティングを行います。

クライアントからサーバーへのリクエストは、サーバー上でルーティングする必要があります。サーバーの観点から見ると、Ajax リクエストのルーティングは引き続き行われます。

クライアント側ルーターは#links、バックボーン アプリへのルーティングに使用されます。そのため、誰かが#リンクをクリックすると、ルーターがこれを取得してアクションを実行します。ほとんどの場合、適切なイベントが発生します。

ルーターは非常に異なっており、今のところ、一方を他方の代わりに使用する状況は考えられません。

于 2013-02-18T10:19:53.527 に答える