あなたが見ているフレームワークのほとんど（すべて？）は同じ問題を解決しますが、それらはわずかに異なる方法で、わずかに異なる目標でそれを行います。
これらのプロジェクトはすべて、これらのカテゴリの問題を解決すると言っても過言ではありません。
- 適切なデフォルトのセットを提供する
- ボイラープレートコードを削減する
- BackboneJS構築ブロックの上にアプリケーション構造を提供する
- 作成者がアプリで使用するパターンを抽出する
2011年12月から構築しているマリオネットには、非常に明確な目標と理想がいくつかあります。
- 複合アプリケーションアーキテクチャ
- エンタープライズメッセージングパターンの影響
- モジュール化オプション
- 増分使用（オールオアナッシング要件なし）
- サーバーロックインなし
- これらのデフォルトを簡単に変更できるようにする
- 構成としてコード化/構成オーバー
他のどのフレームワークにも同じ目標がないと言っているのではありません。しかし、私はマリオネットの独自性はこれらの目標の組み合わせから来ていると思います。
複合アプリケーションアーキテクチャ
WinFormsとC＃を使用して、シッククライアントの分散ソフトウェアシステムで5年以上作業しました。デスクトップ、ラップトップ（スマートクライアント）、モバイルデバイス、およびWebアプリケーション用のアプリを作成しました。これらはすべてコア機能セットを共有し、同じサーバーバックエンドで何度も作業しています。今回、モジュール化の価値を学び、コンポジットアプリケーション設計の道を急速に進みました。
基本的な考え方は、アプリケーションのランタイムエクスペリエンスを「構成」して、必ずしもお互いを認識しているわけではない多くの小さな個々の部分から処理することです。複合アプリケーションシステム全体に登録し、分離されたメッセージと呼び出しのさまざまな手段を通じて通信します。
私はブログでこれについて少し書いて、バックボーンの複合アプリケーションアーキテクチャとしてMarionetteを紹介しました。
メッセージキュー/パターン
同じ大規模な分散システムでも、メッセージキュー、エンタープライズ統合パターン（メッセージングパターン）、およびサービスバスを利用してメッセージを処理しました。これは、何よりも、分離されたソフトウェア開発への私のアプローチに多大な影響を与えました。この観点から、シングルプロセスのインメモリWinFormsアプリケーションを目にするようになり、すぐにサーバーサイドとWebアプリケーションの開発がこれに影響を受けました。
これは、バックボーンアプリケーションの設計の見方に直結しました。高レベルのApplicationオブジェクトと、アプリケーション内で作成する各モジュールの両方に対して、Marionetteでイベントアグリゲーターを提供します。
モジュール間で送信できるメッセージについて考えます。コマンドメッセージ、イベントメッセージなどです。また、サーバー側の通信も、同じパターンのメッセージと考えています。いくつかのパターンはすでにマリオネットに組み込まれていますが、まだ組み込まれていないパターンもあります。
モジュール化
コードのモジュール化は非常に重要です。明確に定義された入口と出口を備えた単一の焦点を持つ、小さくてカプセル化されたパッケージを作成することは、重要なサイズと複雑さを持つシステムにとって必須です。
マリオネットは、その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メソッド、またはその他を提供することを選択した場合、マリオネットのリージョンが適切なタイミングでそれを呼び出します。
サーバーロックインなし
さまざまなサーバーテクノロジーの上にバックボーン/マリオネットアプリを構築しています。
- ASP.NET MVC
- Ruby on Rails
- ルビー/シナトラ
- NodeJS / ExpressJS
- PHP /スリム
- ジャワ
- アーラン
- ... もっと
JavaScriptは、ブラウザーでの実行に関してはJavaScriptです。サーバー側のJavaScriptも素晴らしいですが、ブラウザーベースのJavaScriptの記述方法には影響も影響もありません。
私が作成したプロジェクトとクライアントが使用するバックエンドテクノロジーの多様性のため、何らかの理由でMarionetteを単一のサーバー側テクノロジースタックに固定することはできません。ボイラープレートプロジェクトは提供しません。Ruby gemやnpmパッケージは提供しません。マリオネットは特定のバックエンドサーバーを必要としないことを人々に理解してほしい。これはブラウザベースのJavaScriptであり、バックエンドは関係ありません。
もちろん、言語とフレームワークのパッケージを提供している他の人々を完全にサポートします。私はそれらのパッケージをWikiにリストし、人々が必要に応じてさらに多くのパッケージをビルドし続けることを願っています。しかしそれはコミュニティのサポートであり、マリオネットからの直接のサポートではありません。
デフォルトを簡単に変更
ボイラープレートコードを削減し、適切なデフォルトを提供するための取り組み（これはTim BranyenのLayoutManagerから直接「借りた」という考えです）で、他の開発者が私とは少し異なる実装を使用する必要性を認識しています。
<script>デフォルトでUnderscore.jsテンプレートを使用して、テンプレートのインラインタグに基づくレンダリングを提供します。しかし、マリオネットのRendererやTempalteCacheオブジェクトを変更することで、これを置き換えることができます。これらの2つのオブジェクトはレンダリング機能のコアを提供し、特定のテンプレートエンジンとテンプレートをロードするさまざまな方法でこれを変更する方法を示すWikiページがあります。
Marionetteのv0.9を使用すると、さらに簡単になります。たとえば、インラインテンプレートスクリプトブロックの使用をプリコンパイル済みテンプレートに置き換える場合、レンダラーの1つのメソッドを置き換えるだけで済みます。
Backbone.Marionette.Renderer.render = function(template, data){
return template(data);
};
これで、アプリケーション全体で、ビューのtemplate属性にアタッチしたコンパイル済みのテンプレートが使用されます。
Marionette.Asyncアドオンにv0.9を追加して、ビューの非同期レンダリングをサポートできるようにします。Marionetteのデフォルトの動作をできるだけ簡単に置き換えることができるように、引き続き努力しています。
構成としてコード
私は特定のコンテキストで「構成よりも規約」のファンです。それは物事を成し遂げる強力な方法であり、マリオネットはこれの少しを提供します-それほど多くはありませんが、正直に。他の多くのフレームワーク-特にLayoutManager-は、Marionetteが提供するよりも多くの規則を構成に提供します。
これは目的と意図をもって行われます。
私は十分なJavaScriptプラグイン、フレームワーク、アドオン、およびアプリケーションを構築して、規則を意味のある高速な方法で機能させようとすることの苦痛を理解しました。それは速度で行うことができますが、通常はそれを変更できるという犠牲を払って行います。
そのために、私はマリオネットに「構成としてのコード」アプローチをとります。一連の動作を変更する静的な値をオブジェクトリテラルに提供できる、多くの「構成」APIは提供していません。代わりに、注釈付きのソースコードと実際のAPIドキュメントの両方を使用して、Marionetteを希望どおりに動作するように変更する方法を説明する目的で、各オブジェクトが持つメソッドを文書化します。
Marionetteオブジェクトにクリーンで明確なAPIを提供することにより、特定のオブジェクトまたはMarionette全体の動作を置き換えることが比較的単純で非常に柔軟な状況を作り出します。「単純な」構成API呼び出しを犠牲にして、独自のコードを提供して、物事を思い通りに機能させる柔軟性を提供します。
マリオネットには「構成」または「オプション」APIはありません。しかし、マリオネットの動作を簡単に変更できる、明確なシグネチャを備えた非常に特定の目的を果たす多数のメソッドがあります。
