4

多くの皆さんと同じように、私も JSON のみを扱うバックエンド (私の場合は Django または Rails) を使用して、ますます多くの Web アプリケーションを作成し始めています。

フロントとして、Backbone.js などの MVC クライアントを使用しています。私によると、このソリューションは非常に優れており、多くの種類のアプリケーションでうまく機能します。

私が煩わしいと思ったのは、ほとんど同じことを行う Javascript コードを大量に作成していることに気づきました。新しいアプリケーションごとに、Backbone の上に新しいレイヤーを作成しているように感じます。私がここで考えている方法には、何か問題があるに違いありません。

例を挙げましょう：

6 つのコレクションを提供する API があり、Twitter Bootstrap を使用してこれを表示したいとします。これらの各コレクションを選択して表示できるナビゲーション メニューが表示されます。

すべてのモデル、コレクション、ビュー、およびルーティングとナビゲーションに関するロジックを設定するだけで、多くの Javascript コードが必要になります。また、どのビューがアクティブかを考慮する必要があります。

そのような：

コレクション取得時のエラー処理

コレクションがロードされている場合、「ロード中」と表示されます。失敗した場合は、その理由を確認します。作成/保存/削除と同じです。

ルーティング

最終的に一致する URL:s で特定のビューをレンダリングするだけの複雑なロジックを書いていることに気付きました。インスタンス化されたすべてのビューを含む単なる配列です。ビューさえ必要なく、URL に関連付けられたテンプレートだけが必要な場合があります。6 つのメニューがあれば、6 つの機能を持つことができます。しかし、メニューの深さが 3 レベルで、それぞれに 6 つのオプションがある場合、各ビューにルート機能を設定することはできません。

ナビゲーション バーとブレッドクラム

これは、上記の複雑なロジックから呼び出されるビューになります。ナビゲーションが複数レベルの深さである場合、これは非常に複雑になる可能性があります。

私の質問は次のとおりです。私はここでとてもユニークですか? そうでない場合、これをどのように解決しますか？

Backbone.js は私には適していませんか? どの代替案がより適しているでしょうか (ああ、そうです、私は検索しました)?

お時間をいただきありがとうございます。すべてのアイデアに本当に感謝しています。

4

1 に答える 1

15

ここには 2 つの要因が関係していると言えます。

  1. フレームワーク自体が非常に小さく単純であるため、バックボーン アプリケーションは簡単に冗長になります。Backbone にないすべての機能とコード行について、記述する必要があります。これは、その根底にある哲学の一部です。ドキュメントからの引用：

    Backbone.js は、野心的なインターフェイスを備えたデータが豊富な Web アプリケーションが必要とする共通の基盤を提供することを目的としています。一方で、自分でできるようになった決定を下すことによって窮地に追い込まれることを非常に慎重に回避しています。

    したがって、それはトレードオフです。Ember.js やAngularJSなど、より全体的なフレームワークが他にもあり、独自のコードベースで生成されるボイラープレート コードがはるかに少なくなる傾向があります。どちらも一流のフレームワークであり、ぜひ検討してみてください。もちろん、トレードオフは、フレームワークのサイズが大きくなり、サードパーティの複雑さが増し、「隅に追いやられる」リスクがあります。

    Backbone にとどまりたいが、フレームワークからさらに助けが必要だと感じた場合は、Backbone.Marionetteを調べてください。個人的に使用したことはありませんが、少ないコードと保守可能な構造で多くの一般的な問題を解決する優れた方法のように思えます。

  2. おそらく Backbone だけでうまくいくでしょう。Backbone Model- View-Routerパターンは、複雑で大規模なアプリケーションについて話している場合に限られます。Backbone は、正しい方法を示すのに特に優れているわけではありません。

    コードを繰り返し始めるときは、リファクタリングし、一般化し、DRY に保つ必要があります。例えば：

    • jQuery.ajaxローディング アイコンを 1 か所で定義するには、イベントまたはオーバーライドにフックしますBackbone.sync。
    • 単純なルート アクションの場合は、宣言型route->viewマップを定義し、必要に応じてオプションのルート パラメーターと自動配線の依存関係を使用します。これらを階層化し、このマップに基づいてナビゲーション ビュー コンポーネントを生成します。
    • ブレッドクラムをフックして、Backbone.history.navigateルート フラグメントをローカライズされた UI テキストに自動的にマップします。

    .

    いくつかの一般的なソフトウェア開発パターンを適用し、ロジックを基本クラス、サービス、ユーティリティ、ウィジェット、デコレータ、ミックスイン、および what-have-yous にカプセル化することで、バックボーン アプリケーションを小さな 50 ライナーから 50 000 以上の LOC ビーストに拡張することができました。 . これは大規模な Rails プロジェクトと何ら変わりません。アプリケーションの複雑さとサイズが大きくなると、コードの衛生状態と構造化されたパターンの需要が高まります。

    プロジェクト間で一般化されたソリューションを転送するには、それぞれからスタンドアロン コンポーネントを作成します。あなたが提供した例のうち、私は非常に簡単に形成することBackbone.LoadingIndicatorができます。これをさらに進めるには、コンポーネントをBowerなどでパッケージ化し、それらを依存関係としてプロジェクトに含めます。Backbone.NavigationBackbone.Breadcrumb

あなたの質問に対する正しい答えはありませんが、Backbone アプリは、あなたが説明した以上に拡張できると言っても過言ではありません。スケーリングを行うことを期待しているだけで、その見返りに、フレームワークが要求する方法ではなく、アプリケーションを構築する必要がある方法でアプリケーションを構築する自由が与えられます。いつものように、選択はあなた次第です。

于 2013-02-06T09:18:48.220 に答える