あなたが見ているフレームワークのほとんど（すべて？）は同じ問題を解決しますが、それらはわずかに異なる目標でわずかに異なる方法でそれを行います。
これらのプロジェクトはすべて、これらのカテゴリの問題を解決すると言っても過言ではありません。
- 賢明なデフォルトのセットを提供する
- ボイラープレートコードを減らす
- BackboneJSビルディングブロックの上にアプリケーション構造を提供する
- 著者がアプリで使用するパターンを抽出する
私が2011年12月から構築しているマリオネットには、いくつかの非常に明確な目標と理想も念頭に置いています。
- 複合アプリケーションアーキテクチャ
- エンタープライズメッセージングパターンの影響
- モジュール化オプション
- 増分使用（オールオアナッシングの要件なし）
- サーバーのロックインなし
- これらのデフォルトを簡単に変更できるようにする
- 設定より規約/設定より規約
他のフレームワークのどれもこれらの同じ目標を持っていないと言っているのではありません。しかし、マリオネットの独自性は、これらの目標の組み合わせに由来すると思います。
複合アプリケーションアーキテクチャ
私は、WinFormsとC＃を使用したシッククライアントの分散ソフトウェアシステムで5年以上働いていました。デスクトップ、ラップトップ（スマートクライアント）、モバイルデバイス、およびWebアプリケーション用のアプリを作成しました。これらはすべてコア機能セットを共有し、同じサーバーバックエンドで何度も動作します。今回、私はモジュール化の価値を学び、複合アプリケーション設計の道を非常に急速に進みました。
基本的な考え方は、アプリケーションのランタイムエクスペリエンスを「構成」し、必ずしも相互に認識しているとは限らない多数の小さな個々の部分から処理することです。それらは、複合アプリケーションシステム全体に登録され、分離されたメッセージや呼び出しのさまざまな手段を介して通信します。
これについてブログに少し書いたので、Backboneの複合アプリケーションアーキテクチャとしてMarionetteを紹介しました。
メッセージキュー/パターン
同じ大規模な分散システムでも、メッセージキュー、エンタープライズ統合パターン（メッセージングパターン）、およびサービスバスを利用してメッセージを処理しました。これは、何よりも、分離されたソフトウェア開発への私のアプローチに多大な影響を及ぼしました。私はこの観点から単一プロセスのメモリ内WinFormsアプリケーションを見始め、すぐにサーバー側とWebアプリケーション開発がこれから影響を受けました。
これは、私がBackboneアプリケーションの設計をどのように見ているかに直接変換されています。マリオネットで、高レベルのApplicationオブジェクトと、アプリケーション内で作成する各モジュールの両方にイベントアグリゲーターを提供します。
モジュール間で送信できるメッセージ（コマンドメッセージ、イベントメッセージなど）について考えます。また、サーバー側の通信も同じパターンのメッセージだと思います。いくつかのパターンはすでにマリオネットに浸透していますが、まだ浸透していないパターンもあります。
モジュール化
コードのモジュール化は非常に重要です。明確に定義された入口点と出口点を備えた単一の焦点を持つ、小さく、十分にカプセル化されたパッケージを作成することは、あらゆる重要なサイズと複雑さのシステムにとって必須です。
マリオネットは、その定義を通じて直接モジュール化を提供しmoduleます。しかし、RequireJSが好きで、それを使いたいと思っている人もいることも認識しています。そのため、標準ビルドとRequireJS互換ビルドの両方を提供します。
MyApp = new Backbone.Marionette.Application();
MyApp.module("MyModule", function(MyModule, MyApp, Backbone, Marionette, $, _){
// your module code goes here
});
（これに関するブログ投稿はまだありません）
増分使用
これは、私がマリオネットのすべての部分に焼き付ける中心的な哲学の1つです。つまり、マリオネットを使用するための「オールオアナッシング」の要件はありません。
バックボーン自体は、すべてのビルディングブロックオブジェクトに対して非常に段階的でモジュール式のアプローチを採用しています。いつ、使用したいものを自由に選択できます。私はこの原則を強く信じており、マリオネットが同じように機能するように努めています。
そのために、私がマリオネットに組み込んだピースの大部分は、スタンドアロンで動作し、バックボーンのコアピースと連携し、さらにうまく連携するように構築されています。
たとえば、ほぼすべてのバックボーンアプリケーションは、画面上の特定の場所にバックボーンビューを動的に表示する必要があります。アプリは、古いビューを閉じたり、新しいビューが配置されたときにメモリをクリーンアップしたりする必要もあります。ここで、マリオネットRegionが登場します。リージョンは、ビューを取得し、その上でレンダリングを呼び出し、結果をDOMに詰め込むという定型コードを処理します。次に、ビューに「閉じる」メソッドがある場合は、そのビューを閉じてクリーンアップします。
MyApp.addRegions({
someRegion: "#some-div"
});
MyApp.someRegion.show(new MyView());
ただし、リージョンを使用するためにマリオネットのビューを使用する必要はありません。唯一の要件は、オブジェクトのプロトタイプチェーンのある時点でBackbone.Viewから拡張することです。closeメソッド、メソッド、またはその他を提供することを選択した場合onShow、マリオネットの地域は適切なタイミングでそれを呼び出します。
サーバーのロックインなし
さまざまなサーバーテクノロジーの上にBackbone/Marionetteアプリを構築しています。
- ASP.NET MVC
- Ruby on Rails
- ルビー/シナトラ
- NodeJS / ExpressJS
- PHP/スリム
- Java
- Erlang
- ... もっと
JavaScriptは、ブラウザーでの実行に関してはJavaScriptです。サーバーサイドのJavaScriptも素晴らしいですが、ブラウザーベースのJavaScriptの記述方法には影響も影響もありません。
私が構築したプロジェクトとクライアントが使用するバックエンドテクノロジーは多様であるため、何らかの理由でマリオネットを単一のサーバー側テクノロジースタックに固定することはできません。ボイラープレートプロジェクトは提供しません。rubygemやnpmパッケージは提供しません。マリオネットは特定のバックエンドサーバーを必要としないことを人々に理解してもらいたい。これはブラウザベースのJavaScriptであり、バックエンドは関係ありません。
もちろん、私は他の人々が彼らの言語とフレームワークのためのパッケージを提供することを完全にサポートします。私はそれらのパッケージをWikiにリストし、人々が必要に応じてさらに多くのパッケージを構築し続けることを望んでいます。しかし、それはコミュニティのサポートであり、マリオネットからの直接のサポートではありません。
デフォルトを簡単に変更
ボイラープレートコードを減らし、賢明なデフォルトを提供するための努力の中で（これは、Tim BranyenのLayoutManagerから直接「借用」したアイデアです）、他の開発者が私とは少し異なる実装を使用する必要があることを認識しています。
<script>デフォルトでUnderscore.jsテンプレートを使用して、テンプレートのインラインタグに基づいてレンダリングを提供します。Rendererただし、マリオネットのオブジェクトやオブジェクトを変更することで、これを置き換えることができますTempalteCache。これらの2つのオブジェクトは、レンダリング機能のコアを提供し、特定のテンプレートエンジンおよびテンプレートをロードするさまざまな方法のためにこれを変更する方法を示すwikiページがあります。
マリオネットのv0.9を使用すると、さらに簡単になります。たとえば、インラインテンプレートスクリプトブロックの使用を事前にコンパイルされたテンプレートに置き換える場合は、レンダラーの1つのメソッドを置き換えるだけで済みます。
Backbone.Marionette.Renderer.render = function(template, data){
return template(data);
};
templateこれで、アプリケーション全体で、ビューの属性に添付するコンパイル済みのテンプレートが使用されます。
非同期レンダリングビューをサポートできるv0.9のMarionette.Asyncアドオンも提供しています。私は、マリオネットのデフォルトの動作を可能な限り簡単に置き換えることができるように継続的に努力しています。
構成としてのコード
私は特定の状況での「設定より規約」のファンです。これは物事を成し遂げるための強力な方法であり、マリオネットはこれを少し提供します-正直言って、あまり多くはありませんが。他の多くのフレームワーク（特にLayoutManager）は、Marionetteよりも設定より規約を提供します。
これは、目的と意図を持って行われます。
私は、コンベンションを意味のある高速な方法で機能させようとする苦痛を知るのに十分なJavaScriptプラグイン、フレームワーク、アドオン、およびアプリケーションを構築しました。それはスピードで行うことができますが、通常はそれを変更できるという犠牲を払って行われます。
そのために、私はマリオネットに対して「構成としてのコード」アプローチを採用しています。一連の動作を変更する静的な値を持つオブジェクトリテラルを提供できる「構成」APIはあまり提供していません。代わりに、注釈付きのソースコードと実際のAPIドキュメントの両方を通じて、各オブジェクトが持つメソッドをドキュメント化し、Marionetteを希望どおりに機能するように変更する方法を説明します。
マリオネットオブジェクトにクリーンでクリアなAPIを提供することで、特定のオブジェクトまたはマリオネット全体の動作を置き換えることが比較的簡単で非常に柔軟な状況を作成します。「単純な」構成API呼び出しを犠牲にして、独自のコードを提供して、希望どおりに機能させる柔軟性を実現します。
Marionetteには「configure」または「options」APIはありません。しかし、マリオネットの動作を簡単に変更できる、クリーンな署名を備えた非常に特定の目的を果たす多数のメソッドがあります。
