BinaryDevelop
  1. ホーム
  2. backbone.js

[解決済み] backbone.jsをベースにした数多くのフレームワークの実際の強みと弱みは何でしょうか？[クローズド］

2022-04-16 02:04:01

質問内容

どなたか、最新のbackbone.jsの亜種について、経験を共有していただけると幸いです。 私はいくつかのプロジェクトでbackbone/underscore/requireを使用して良い経験を持っており、複雑なアプリケーション構造に対するより高度なソリューションに向けて次のステップに進みたいと考えています。

以下のようなフレームワークがあることは知っています。

そしておそらく、いくつか見逃しているものもあるでしょう。

ここに違いについての簡単な紹介があります。

が、非常に一般的なものです。これらのフレームワークを使用した実際のアプリケーションの経験を共有できる方がいらっしゃればと思います。

どちらを選ぶとどんなメリットがあるのでしょうか？例えば、marionetteがchaplinより良いソリューションになるのはどんなときか、あるいはvetebraeが特定のアプリケーションに良いのはなぜか、などです。

もちろん、明白な答えは「"」でしょう。 ニーズに合わせて最適なものを使用する しかし、私はこれらのフレームワークを使った経験がないので、その強み、目的、利点、好みのシナリオを知ることができません。

ありがとうございます。

1を編集します。 は、この記事を見つけました。 Backbone.MarionetteとBackbone-Boilerplateの比較

2.編集 Mathias schafer (Chaplin)さんからのメールでの回答です。

要するに、現在の構成は、すでに実運用で使われているため、バージョン1.0に近いものです。1.0まで大きな新機能の追加やAPIの破壊的な変更は予定していません。

Marionetteは、間違いなく、最も包括的で安定したライブラリです。Backboneを使ったJSアプリ開発のいくつかの側面に対応しています。例えば、Backbone 自身が完全に空白にしている強力なビュー層を持っています。もちろん、いくつかの側面はあなたの要求を満たさないことがわかり、Marionetteを中心とした構造を設定する必要性を感じるかもしれない。

これに対して、Chaplinは、Backboneアプリのかなり小さな、しかし非常に重要な側面、すなわちアプリ全体の構造とモジュールのライフサイクルに焦点を合わせています。この点で、Chaplinは、非常に大きな存在であり、ライブラリというよりフレームワークに近い（「あなたのコードはライブラリを呼び、フレームワークはあなたのコードを呼ぶ」のような）。Chaplinは、個々のアプリケーションモジュールの上に位置し、アプリ全体の状態を制御するいくつかの中心的なクラスを提供します。これは、例えばRuby on Railsがそうであるように、あなたのアプリに従来の構造を与えます。

Chaplinでは、コントローラに対応するルートをいくつか宣言し、ルートが一致したらChaplinがコントローラを起動します。また、古いコントローラの廃棄や、コントローラが作成するはずのメインビューの表示・非表示の処理も行っています。これは基本的なアイデアですが、Chaplinはこれをスムーズに実行するために醜い細部の世話をしてくれます。

この構造に付随して、2つの原則があります。 - モジュール化、デカップリング、サンドボックス化 - Publish/SubscribeとMediatorを用いたモジュール間コミュニケーション

もちろん、これらのパターンはソフトウェア開発の世界では目新しいものではなく、Backbone.jsのアプリに適用しているライブラリはChaplinだけではありません。

ChaplinはViewレイヤーの強化も行っており、例えば非常に洗練されたCollectionViewがありますが、全体としてはRegionやLayoutsを持つMarionetteほどではありません。しかし、Chaplin Viewsが提供する手段を使えば、そのようなメタクラスを比較的簡単に書くことができる。

どうやって解決するの？

あなたが見ているフレームワークのほとんど（すべて？）は、同じ問題を解決していますが、わずかに異なる方法で、わずかに異なる目標でそれを行います。

これらのプロジェクトはすべて、これらのカテゴリの問題を解決するものだと言っていいと思います。

  • デフォルトのセンスの良いセットを提供する
  • 定型的なコードの削減
  • BackboneJSのビルディングブロックの上にアプリケーションの構造を提供する
  • 作者がアプリで使用しているパターンの抽出

2011年12月から作っているMarionetteも、いくつかの明確な目標と理想を持っています。

  • 複合アプリケーションアーキテクチャ
  • エンタープライズメッセージングパターンの影響
  • モジュール化オプション
  • インクリメンタルな使用（オール・オア・ナッシングの要求なし）
  • サーバーロックインなし
  • デフォルトを簡単に変更することができます。
  • 設定通りのコード／設定以上のコード

他のフレームワークのどれもが、これらと同じ目標を持っていないとは言いません。しかし、Marionetteのユニークさは、これらの目標の組み合わせから生まれると思います。

コンポジットアプリケーションアーキテクチャ

私は5年以上、WinFormsとC#を使用したシッククライアント型の分散型ソフトウェアシステムに携わってきました。デスクトップ、ラップトップ（スマートクライアント）、モバイルデバイス、ウェブアプリケーションのアプリケーションを構築し、すべてコアとなる機能セットを共有し、同じサーバーバックエンドで何度も作業しました。このとき、私はモジュール化の価値を学び、急速に複合アプリケーション設計の道へと進みました。

基本的な考え方は、アプリケーションのランタイム・エクスペリエンスとプロセスを、必ずしも互いのことを知らない多くの小さな個々の部品で構成することです。これらは、複合アプリケーションシステム全体に自分自身を登録し、分離されたメッセージや呼び出しのさまざまな手段を通じて通信します。

私のブログでも、Backboneのための複合アプリケーション・アーキテクチャとしてMarionetteを紹介し、少し書いています。

メッセージ キュー / パターン

同じ大規模分散システムでも、メッセージキューイング、エンタープライズ・インテグレーション・パターン（メッセージング・パターン）、サービスバスなどを活用して、メッセージを処理していました。このことは、何よりも、私の非連成ソフトウェア開発へのアプローチに多大な影響を与えました。この観点からシングルプロセス、インメモリのWinFormsアプリケーションを見るようになり、やがて私のサーバーサイドやWebアプリケーションの開発にも影響を与えるようになりました。

これはそのまま、Backboneのアプリケーション設計の見方にもつながっています。私はMarionetteで、高レベルのアプリケーション・オブジェクトと、アプリケーション内で作成する各モジュールの両方に、イベント・アグリゲータを提供しています。

コマンドメッセージ、イベントメッセージなど、モジュール間で送信できるメッセージについて考えています。また、サーバーサイドの通信も、これらと同じパターンのメッセージとして考えています。このパターンの中には、すでにMarionetteに取り込まれているものもありますが、まだ取り込まれていないものもあります。

モジュール化

コードのモジュール化は非常に重要です。小さく、うまくカプセル化されたパッケージを作成し、入口と出口を明確に定義した上で焦点を絞ることは、かなりの規模と複雑さを持つシステムにおいて必須です。

Marionette は、モジュール化を直接提供するために module という定義があります。しかし、RequireJSが好きでそちらを使いたい人もいることも認識しています。そこで、標準的なビルドとRequireJS互換のビルドの両方を提供することにしました。 


MyApp = new Backbone.Marionette.Application();

MyApp.module("MyModule", function(MyModule, MyApp, Backbone, Marionette, $, _){

  // your module code goes here

});

(これに関するブログ記事はまだありません)

インクリメンタル使用

これは、私がMarionetteのあらゆる部分に焼き付けている核となる哲学のひとつで、Marionetteの使用に関して「オール・オア・ナッシング」の要件はありません。

Backbone自体は、すべてのビルディング・ブロック・オブジェクトについて、非常に漸進的でモジュール化されたアプローチを取っています。どのオブジェクトを、いつ使うかは自由なのです。私はこの原則を強く信じており、Marionetteが同じように動作するように努力しています。

そのため、私がMarionetteに組み込んだ部品の大半は、単独で動作し、Backboneの中核部品と連携し、さらによく連携するように作られています。

例えば、ほぼすべてのBackboneアプリケーションは、画面上の特定の場所にBackboneビューを動的に表示する必要があります。また、アプリは、古いビューを閉じたり、新しいビューが配置されたときにメモリを掃除したりする処理を行う必要があります。そこで、Marionetteの Region が登場します。リージョンは、ビューを取得し、それに対してレンダーを呼び出し、その結果を DOM に詰め込むというお決まりのコードを処理します。そして、ビューに "close" メソッドがある場合は、ビューを閉じて、あなたのためにそれをきれいにします。 


MyApp.addRegions({
  someRegion: "#some-div"
});

MyApp.someRegion.show(new MyView());

しかし、リージョンを使用するためにMarionetteのビューを使用する必要はありません。唯一の要件は、オブジェクトのプロトタイプチェーンのある時点で、Backbone.Viewから拡張していることです。もし、あなたが close メソッドを使用すると onShow メソッドなどを、Marionetteのリージョンが適切なタイミングで呼び出してくれます。

サーバーロックインなし

私は、さまざまなサーバー技術の上にBackbone / Marionetteアプリを構築しています。

  • ASP.NET MVC
  • ルビーオンレイルズ
  • ルビー / シナトラ
  • NodeJS / ExpressJS
  • PHP / スリム
  • Java
  • Erlang
  • ... など

ブラウザ上で動作するものであれば、JavaScriptはJavaScriptです。サーバーサイドのJavaScriptも素晴らしいのですが、私がブラウザベースのJavaScriptをどう書くかについては、何の影響もありませんし、影響もありません。

私が構築したプロジェクトや顧客が使用するバックエンド技術は多様であるため、いかなる理由であれ、Marionetteを単一のサーバーサイド技術スタックに固定することはできませんし、今後もそうするつもりはありません。ボイラープレート・プロジェクトは提供しません。Rubyのgemやnpmのパッケージも提供しません。Marionetteは特定のバックエンドサーバーを必要としないことを理解してほしいのです。ブラウザベースのJavaScriptであり、バックエンドは関係ないのだ。

もちろん、他の人が自分の言語やフレームワークのパッケージを提供することは、全面的に支持します。私はそれらのパッケージをWikiに掲載し、人々が必要性を感じてさらにパッケージを構築し続けることを望んでいます。しかし、それはコミュニティのサポートであって、Marionetteからの直接的なサポートではありません。

簡単にデフォルトを変更できる

定型的なコードを減らし、賢明なデフォルトを提供するための私の努力（これは Tim Branyen の LayoutManager から直接借りたアイデアです）において、他の開発者が私とはわずかに異なる実装を使用する必要性を認識しています。

インラインでのレンダリングを提供します。 <script> タグをテンプレートに使用し、デフォルトではUnderscore.js templatingを使用しています。しかし、これを置き換えるには Renderer および TempalteCache オブジェクトを作成します。この2つのオブジェクトはレンダリング機能の核となるもので、特定のテンプレートエンジンやテンプレートの読み込み方法の違いによってこれを変更する方法を示すwikiページがあります。

Marionetteのv0.9では、それがさらに簡単になりました。たとえば、インライン テンプレート スクリプト ブロックの使用をプリコンパイル テンプレートに置き換えたい場合、レンダラのメソッドを 1 つ置き換えるだけです。 


Backbone.Marionette.Renderer.render = function(template, data){
  return template(data);
};

で、アプリケーション全体がプリコンパイルされたテンプレートを使用するようになり、ビューの template 属性で指定します。

さらに、ビューの非同期レンダリングをサポートする Marionette.Async アドオンを v0.9 で提供します。私は、Marionetteのデフォルトの振る舞いをできるだけ簡単に置き換えることができるよう、常に努力しています。

設定としてのコード

私は、ある種の文脈では「設定より慣習」（convention over configuration"）のファンです。これは物事を成し遂げるための強力な方法であり、Marionetteはこれを少しばかり提供しています（正直なところ、それほど多くはありませんが）。他の多くのフレームワーク、特にLayoutManagerは、Marionetteよりも設定に関する慣習を提供しています。

これは目的と意図を持って行われるものです。

私は、JavaScriptのプラグインやフレームワーク、アドオン、アプリケーションを十分に作ってきたので、規約を有意義かつ高速に動作させようとすることの苦痛を知っています。スピードは出せるが、たいていは変更できないという代償を払うことになる。

そのため、私はMarionetteに対して、"code as configuration"というアプローチをとっています。私は、静的な値を持つオブジェクト・リテラルを提供することで、さまざまな動作を変更できるような、多くのquot;設定APIを提供しません。その代わり、各オブジェクトが持つメソッドを、注釈付きのソースコードと実際のAPIドキュメントの両方を通して文書化し、Marionetteをあなたの望むように動作させる方法を伝えることを意図しています。

Marionetteオブジェクトのためのクリーンで明確なAPIを提供することで、特定のオブジェクトやMarionette全体の動作を置き換えることが比較的簡単で、非常に柔軟な状況を作り出しています。私は、自分の望むように物事を動かすために自分のコードを提供する柔軟性のために、quot;simple" 設定APIコールを犠牲にしています。

Marionetteには、"configure" や "options" のようなAPIは見当たりません。しかし、Marionette がどのように動作するかを簡単に変更できるように、きれいなシグネチャを持つ、それぞれが非常に特定の目的を果たす多数のメソッドを見つけることができます。

関連

最新

おすすめ

について
/
プライバシー・ポリシー
/
お問い合わせ
© 2022 BinaryDevelop. すべての権利は、それぞれの所有者に帰属します