22

複数ページのJavaScriptアプリケーションを構築しています。デザインパターンをよく読み、コア/ファサード/モジュールアプローチとルーズカップリング（イベントへのpub / subスクライブ）を使用してアプリケーションを作成しました。

デプロイ時にすべてのモジュールファイルと関連する依存関係を最小化して単一の外部JavaScriptファイルに結合する非常に優れたシステムを構築しました。アプリケーションの余分なHTTP要求を最小限に抑えることが設計目標です。したがって、AMD（非同期モジュール定義）にはあまり関心がありません。

NicholasZakasのプレゼンテーションである スケーラブルなJavaScriptアプリケーションアーキテクチャで定義されたガイドラインを使用しています

http://www.youtube.com/watch?v=vXjVFPosQHw

&&

大規模なJavaScriptアプリケーションアーキテクチャのため のAddyOsmaniのパターンhttp://addyosmani.com/largescalejavascript/

&&

このプレミアムチュートリアルは、NettutsのAndrew Burgessによる、モジュラーJavaScriptの作成 http://marketplace.tutsplus.com/item/writing-modular-javascript/128103/?ref=addyosmani&ref=addyosmani&clickthrough_id=90060087&redirect_back=true

私の質問は、このアプリケーションとそれに関連するモジュールのさまざまなページを管理する方法についてのアドバイスです。また、BackbonejsのRouterクラスとballuptonのHistory.jsライブラリを使用して、HTML5の履歴/状態APIを操作し、HTML状態APIをサポートしない古いブラウザーの下位互換性を維持しながら、更新せずにページを動的に読み込みます。私のすべてのページは、共通のコードベース（単一の縮小および圧縮されたjsファイル）を共有しています。

これが私のアプリケーションで使用することを考えている構造の概​​要です： ここに画像の説明を入力してください

これは本質的にハイブリッドアプローチです。上半分は、相互に直接相互作用せず、ファサードを介して通知をパブリッシュ/サブスクライブする個別のモジュールを備えたコア/ファサード/モジュールパターンで構成されています。

下半分は、提案されたアプリケーション構造で構成されています。これは、状態/ URLが変更されたときに「メインコントローラー」に通知し、メインコントローラーはグローバル操作を実行します（まだ初期化されていない場合は、UIのヘッダーとサイドバーメニューを初期化するなど）そして、は関連するサブコントロールに、そのinit（）メソッドを実行するように指示します（以前にロードされたコントローラーでdestroy（）;を呼び出します）。各サブコントローラー（例：ホームページ、カレンダーページ、予約ページなどに対応）は、使用可能なモジュールのプールからモジュールを選択して初期化します。

これは良いアプローチですか、それとも私は悪い方向に進んでいますか？モジュールはまだ互いに独立していることがわかります。これはスケーラビリティに優れています。

また、ルーターとコントローラーを個別のモジュールとして扱い、コアにパブリッシュ/サブスクライブさせることも検討しました。各コントローラーは、ページに必要なモジュールを何らかの方法で初期化します。

4

2 に答える 2

6

履歴をスムーズに機能させるために私たちが行ったことの 1 つは、最初に URL を変更することでした。URL が変更されるとイベントがトリガーされ、ルーターは URL を解析して何をすべきかを判断します。このイベントは、ページの読み込み時にも自動的にトリガーされます。リンクをクリックすると、URL が変更されるだけです。これは非常に単純で、アプリケーション ロジックからリンク/ボタンを完全に切り離します。これは、私たちのアプリケーションではうまくいくように見えました。私たちは JQM を使用しましたが、いくつかの XML ファイルからほとんどの指示を読み、メインのビューポート領域にロードする HTML ページの束がなかったため、ルーターのほとんどを削除しました。

バックボーン アプリがルーターをコア/メディエーターとして使用するのをよく見てきました。これは良い考えです。URL の変更イベントをリッスンするだけで、ページを適切に変更できます。このメディエーターはおそらくシングルトンである必要がありますが、シングルトンは単体テストが困難です。

私が Backbone に必ずしも同意しなかったのは、その「ビュー」の定義でした。ビューは、コントローラーのアクションのように見えます (いくつかの観点からはそうです)。その時点で、アプリケーションに別のレベルの分離を追加しました。私たちのビューは、いくつかの JSON と handlebars.js で埋められたテンプレート ファイルに ajax リクエストを作成しました。ヘッダー/サイドバーは単なるテンプレートであるべきだと思います。それらを更新する必要がある場合は、非常に簡単に実行できる方法を確認してください。それ以外の場合は、リストのコレクション、各アイテムのモデル、コレクション ビュー、およびモデル ビューの 4 つの新しいモジュールを作成することを検討しています。テンプレートをさらに分解する必要があるまで、より高いレベルのビューとテンプレートをより緊密に結合します (たとえば、「アプリケーション/メイン ビュー」など)。

このテンプレート レイヤーを使用すると、再コンパイルせずに表面的な変更を加えることができます。これは素晴らしいことです。物事を「メタ」に入れることができるときはいつでも、それは勝利です（XMLを読む必要がない限り（ha））。おまけとして、テンプレートを個別にキャッシュすることもできます (または、個別にキャッシュ バストすることもできます)。

ただし、アーキテクチャは問題ないように見えますが、問題に対する有効なアプローチです。私が提供する 1 つのヒントは、前もって設計しすぎないことです。繰り返すのが一番です。リファクタリングが必要になります。3 ～ 6 か月前に、アプリケーションの流れをよりスムーズにするものを予測することは不可能です。

2013 年 12 月 18 日の更新

現在、私たちはマリオネットやその他のアドディ オスマニ トリックを使用しています。上記の項目に加えて、AMD の代替フォーマットを使用しています。

define(function(require) {
    var myTemplate = require('hb!mytemplate.handlebars'),
        view = require('myview');
    ...
});

また、リクエスト/レスポンス レイヤーを提供する wreqr と組み合わせて marionette アプリケーション クラスを使用しています。これにより、アプリケーション全体のオブジェクトをきれいに設定できます。また、クラス名を明示的に指定せずにクラスを定義することもできます。これは、サンドボックス化するための非常に優れた方法です。例えば：

this.app.setHandler('CanvasClass', function() {
    return RaphaelCanvasView;
});

// elsewhere

this.app.request('CanvasClass').text('123', {x:1, y:2});

これはすべてかなりうまくいくようです。

aura js と Web コンポーネントもチェックアウトする必要があります。私たちのディレクトリ構造は、まだそれらに投資することなく、それらの概念を模倣/予測しています。

于 2012-11-02T20:02:52.723 に答える
2

良いアプローチだと思います。私は 2 つの巨大な商用 Web アプリ (マイナスのバックボーンとカスタム履歴マネージャーを使用) で同様のものを開発してきましたが、うまく機能します。また、AMD も使用しておらず、すべてのやり取りは pub/sub によって処理されます。私の最高のインスピレーションの 1 つ (既にご存知だと思います) は、https ://github.com/aurajs/aura です。

于 2012-11-09T15:35:58.323 に答える