PPTダウンロードアドレスのPDFバージョン：http：//www.slideshare.net/jibyjohnc/jqquerysummit-largescale-javascript-application-architecture
注：照合プロセス中に、著者の考えが繰り返されることがわかりました。そのため、彼はそれらのいくつかを削除しました。あなたの英語が良い場合は、英語のPPTを直接読んでください。
この記事の主な章は次のとおりです。
1。「JavaScript大規模プログラム」とは何ですか？
2。現在のプログラムアーキテクチャを検討してください
3。長期的な考慮事項
4。ブレインストーミング
5。推奨されるアーキテクチャ
5.1デザインパターン
5.1.1モジュール理論
5.1.1.1概要
5.1.1.2モジュールモード
5.1.1.3オブジェクトセルフフェイスサイズ
5.1.1.4 CommonJSモジュール
5.1.2ファサードモード
5.1.3メディエーターモード
5.2アーキテクチャに適用します
5.2.1ファサード - コア抽象化
5.2.2メディエーター - プログラムコア
5.2.3緊密に動作します
6.パブ/サブエクステンションの公開：自動登録イベント
7。Q＆A
8。謝辞
「JavaScript大規模プログラム」とは何ですか？
開始する前に、大きなJavaScriptサイトとは何かを定義しましょう。多くの経験豊富なJS開発の専門家も挑戦されています。一部の人々は、100,000行以上のJavaScriptコードが大きいと見なされていると言う人もいれば、JavaScriptコードはサイズが1MBを超える必要があると言う人もいます。実際、コードの量をインストールされたコードの数として測定できないため、どちらも正しくありません。多くの些細なJSコードは、100,000行を簡単に超えることができます。
「大きな」の私の定義は次のとおりです。それは正しくないかもしれませんが、比較的近いはずです：
私は個人的に、大規模なJavaScriptプログラムは非常に重要であり、ヘビー級データを処理してブラウザに表示するための多くの優れた開発者の取り組みを取り入れているべきだと思います。
現在のプログラムアーキテクチャを確認します
この問題がどれほど重要かを強調することはできません。多くの経験豊富な開発者は、「既存のクリエイティブとデザインのパターンは私の以前の中規模プロジェクトで非常にうまく機能しているので、わずかに大きなプログラムで再び使用することは問題ありません」と言うことがよくあります。特定のプログラムでは事実ですが、大規模なプログラムであるため、通常、分解して注意を払う必要がある大きな懸念があるはずです。長い間実行されてきたプログラムアーキテクチャをレビューするのに時間がかかる方法を簡単に説明します。ほとんどの場合、現在のJavaScriptプログラムアーキテクチャは次のように見えるはずです（それはJSアーキテクチャであり、誰もがASP.NET MVCと呼ぶものではないことに注意してください）：
カスタムウィジェット
モデル
ビュー
コントローラー
テンプレート
ライブラリ/ツールキット
アプリケーションコア。
また、プログラムを複数のモジュールだけにカプセル化するか、他のデザインパターンを使用することもできますが、これは素晴らしいことですが、これらの構造がアーキテクチャを完全に表している場合、潜在的な問題があるかもしれません。いくつかの重要なポイントを見てみましょう。
1.あなたのアーキテクチャにいくつのものを取り出して再利用できますか？
他のコードに依存しない個別のモジュールはありますか？それは自己完結型ですか？使用しているコードベースに移動してから、モジュールモジュールコードを選択して新しいページに配置すると、すぐに使用できますか？原則は大丈夫だと言うかもしれません。長い間計画することをお勧めします。あなたの会社が以前に多くの重要なプログラムを開発したことがある場合、突然いつか誰かがこのプロジェクトのチャットモジュールが良いと言ったので、それを取り出して別のプロジェクトに入れましょう。コードを変更せずに使用できますか？
2.システムは他のモジュールに依存する必要があるモジュールはいくつありますか？
システムのすべてのモジュールはしっかりと結合されていますか？この質問を懸念として取る前に、最初に説明します。すべてのモジュールに依存関係がないことではありません。たとえば、細粒関数はベース関数から拡張される場合があります。私の問題はこの状況とは異なります。さまざまな機能モジュールの前の依存関係について話している。理論的には、すべての異なる機能モジュールには、あまり多くの依存関係がないはずです。
3.プログラムの一部に何か問題が発生した場合、他の部分はまだ機能しますか？
Gmailと同様のプログラムを構築すると、Gmailの多くのモジュールが動的にロードされていることがわかります。これは、ページの初期化時にロードされないチャットチャットモジュールなど、ロード後にエラーが発生した場合でも、ページの他の部分を正常に使用できます。
4.モジュールを非常に簡単な方法でテストできますか？
各モジュールは、数百万人のユーザーがいる大きなサイトで使用される場合があります。または、複数のサイトでも使用するため、モジュールはテストに耐える必要があります。つまり、アーキテクチャの内側または外側であろうと、さまざまな環境で渡すことができるほとんどの主張を含めて、非常に簡単にテストできるはずです。
長期的な考慮事項
大規模なプログラムを構成するとき、最も重要なことは将来を見据えていることです。 1か月または1年後にのみ状況を考慮することはできません。長期にわたって変化の可能性を考慮する必要がありますか？開発者は、多くの場合、DOM操作コードとプログラムを強くバインドしすぎていますが、別のモジュールに個別のロジックをカプセル化している場合があります。長期的にはあまり良くない理由を考えてください。
私の同僚は、かつて正確なアーキテクチャは将来のシナリオには適していないかもしれないと言っていましたが、それは正しいこともありますが、それをする必要があるとき、あなたはたくさんのお金を払うでしょう。たとえば、特定のパフォーマンス、セキュリティ、および設計上の理由で、Dojo、Jquery、Zepto、およびYuiを交換することを選択する必要がある場合があります。現時点では、問題があります。ほとんどのモジュールには依存関係があり、お金、時間、そして人が必要ですよね？
一部の小さなサイトでは問題ありませんが、大きなサイトは、さまざまなモジュール間のさまざまな問題を心配することなく、より柔軟なメカニズムを提供する必要があります。これはお金と時間を節約します。
要約すると、プログラム全体を書き直さずにクラスライブラリを置き換えることができることを確認できますか？そうでない場合は、以下でお話しようとしていることは、より適しています。
多くの経験豊富なJavaScript開発者がいくつかの重要なメモを提供しています。
Javascriptmvcの著者であるJustin Meyerは次のように述べています。
大規模なプログラムを構築するための最大の秘密は、大規模なプログラムを構築することは決してないが、プログラムを小さなモジュールに分割して、各小さなモジュールをテスト可能でかなり大きくし、プログラムに統合することです。
高性能JavaScriptのウェブサイト著者Nicholas、Zakas：
「重要なのは、これがどのように成長するのかわからないことを最初から認めることです。すべてを知らないことを受け入れると、システムを防御的に設計し始めることができます。それに少し時間を費やす可能性のある重要な領域を特定します。たとえば、他のシステムと通信するアプリの一部が変更される可能性が高いことを期待する必要があります。」 -
多くのテキストの問題は面倒です。要約すると、すべてを変更できるため、抽象的でなければなりません。
jQueryの基礎著者レベッカ・マーフィー：
各モジュール間の接続が近いほど、再利用性が低くなり、変更の難しさが大きくなります。
上記の重要な見解は、アーキテクチャを構築するための中核的な要素であり、常にそれらを覚えておく必要があります。
ブレインストーミング
ブレインストーミングをしましょう。モジュール間に依存関係がなく、各モジュールとプログラムが通信し、中間層が対応するメッセージを引き継ぎ、処理するゆるい結合アーキテクチャが必要です。
たとえば、オンラインベーカリープログラムを構築するJavaScriptがある場合、モジュールは「配信する必要がある42ラウンドがあります」というメッセージを送信します。さまざまなレイヤーレイヤーを使用して、モジュールから送信されたメッセージを処理し、次のことを行います。
モジュールは、プログラムコアに直接アクセスしません
モジュールは、直接呼び出したり、他のモジュールに影響したりしません
これにより、特定のモジュールのエラーにより、すべてのモジュールでエラーを作成できなくなります。
別の問題はセキュリティです。本当の状況は、ほとんどの人が内部セキュリティが問題だとは考えていないということです。私たちは心の中で、プログラムは自分で構築されていると言います。どのものが公開され、プライベートであるかを知っています。セキュリティに問題はありませんが、プログラムコアにアクセスするモジュールを定義する方法はありますか？たとえば、チャットチャットモジュールは、管理モジュールを呼び出したくないか、DB書き込み許可を持つモジュールを呼び出したくないので、それらの間に脆弱性があり、XSS攻撃を引き起こすのは簡単です。各モジュールはすべてを実行できないはずですが、ほとんどのアーキテクチャのJavaScriptコードには現在、この問題があります。中間層を提供して、どのモジュールがその承認された部品にアクセスできるかを制御します。つまり、モジュールは承認された部分のほとんどしか達成できません。
提案されたアーキテクチャ
私たちの記事の焦点は、今回は私たちが提案するアーキテクチャが私たち全員がよく知られているデザインパターン、モジュール、ファサード、メディエーターを使用することです。
従来のモデルとは異なり、各モジュールを切り離すために、モジュールがいくつかのイベントイベントを公開するだけです。メディエーターモードは、これらのモジュールからのメッセージメッセージを購読し、通知応答を制御する責任を負います。ファサードモードユーザーは、各モジュールの権限を制限します。
以下は、注意する必要がある部分です。
1デザインパターン
1.1モジュール理論
1.1.1概要
1.1.2モジュールモード
1.1.3オブジェクトの自己顔のサイズ
1.1.4 CommonJSモジュール
1.2ファサードモード
1.3メディエーターモード
2アーキテクチャに適用します
2.1ファサード - コア抽象化
2.2メディエーター - プログラムコア
2.3緊密に連携します
モーダル理論
誰もがモジュラーコードを多少使用している可能性があります。このモジュールは、完全で堅牢なプログラムアーキテクチャの一部です。各モジュールは、別の目的のために作成されます。 Gmailに戻って、例を見てみましょう。チャットチャットモジュールは別の部分のようですが、実際には多くの個別のサブモジュールがあります。たとえば、内部の式モジュールは実際には別のサブモジュールであり、これはウィンドウで電子メールを送信するためにも使用されます。
もう1つは、モジュールを動的にロード、削除、交換できることです。
JavaScriptには、モジュールを実装するいくつかの方法があります。誰もがモジュールパターンとオブジェクトリテラルに精通しています。すでにこれらに精通している場合は、このセクションを無視して、CommonJSパーツに直接ジャンプしてください。
モジュールモード
モジュールパターンは、比較的人気のあるデザインパターンです。ブレースを通じて、私的変数、方法、および状態をカプセル化できます。これらの内容を包むことにより、一般にグローバルオブジェクトに直接アクセスすることはできません。この設計パターンでは、1つのAPIのみが返され、他のすべてのコンテンツはプライベートとしてカプセル化されています。
さらに、このパターンは、自己実行された関数式に似ています。唯一の違いは、モジュールがオブジェクトを返し、自己実行された関数式が関数を返すことです。
私たち全員が知っているように、JavaScriptは他の言語にアクセス修飾子を持つことを望んでおらず、各フィールドまたはメソッドのプライベートモディファイとパブリック修飾子を宣言することはできません。では、このパターンをどのように実装しますか？つまり、内部オブジェクトを呼び出す機能を持ついくつかのパブリック方法を含むオブジェクトを返すことです。
以下のコードをご覧ください。このコードは自己実行コードです。宣言には、グローバルオブジェクトBatterymoduleが含まれます。バスケットアレイはプライベートであるため、プログラム全体がこのプライベート配列にアクセスできません。同時に、3つのメソッド（additem、getItemcount、gettotalなど）を含むオブジェクトを返します。これらの3つの方法は、プライベートバスケットアレイにアクセスできます。
var basketmodule =（function（）{var basket = []; // privatereturn {// public additem：function（values）{basket.push（values）;}、getItemcount：function（）{return basket.length;}、gettotal：function（）{qu q = thisetitemcount（）、p = 0;バスケット[q] .price;また、返品されたオブジェクトはBasketModuleに直接割り当てられているため、次のように使用できます。
// BasketModuleは、MethodSbaskEtModule.Additem（{item： 'Bread'、frice：0.5}）; BasketModule.Additem（{item： 'butter'、fort：0.3}）; console.log（basketmodule.getItemcount（））; console.log（basketmodule.getTotal（））; //ただし、以下は機能しません。console.log（basketmodule.basket）; //（返されたオブジェクトの内側ではないと未定）console.log（basket）; //（閉鎖の範囲内にのみ存在します）では、さまざまな人気のあるクラスライブラリ（Dojo、jQueryなど）でどのようにそれを行いますか？
道場
DojoはDojo.declareを使用して、クラススタイルの宣言方法を提供しようとします。モジュールパターンを実装するために使用できます。たとえば、ストアネームスペースの下でバスケットオブジェクトを宣言したい場合は、これを行うことができます。
//従来のWayvar store = window.store || {}; store.basket = store.basket || {}; // dojo.setobjectdojo.setObject（ "store.basket.object"、（function（）{var basket = []; function privatemethod（）{console.log（basket）;} return {publicmethod：function（）{privatemethod（）;}};}（}（））;Dojo.Provideと組み合わせると非常に強力です。
ユイ
次のコードは、Yuiの元の実装です。
yahoo.store.basket = function（）{// "private"変数：var myprivatevar = "yahoo.store.basket。"内でのみアクセスできます。 "; // "private"メソッド：var myprivatemethod = function（）{yahoo.log（ "yahoo.store.basket"）;内からのみアクセスできます。 } return {mypublicproperty： "私は公共の財産です。"、mypublicmethod：function（）{yahoo.log（ "私はパブリックメソッドです。"）; //バスケット内で、「プライベート」varsと方法にアクセスできます：yahoo.log（myprivatevar）; yahoo.log（myprivatemethod（））; // myPublicMethodのネイティブスコープはストアなので、「this」：yahoo.log（this.mypublicproperty）を使用してパブリックメンバーにアクセスできます。 }};}（）;jquery
jQueryにはモジュールパターンの多くの実装があります。別の例を見てみましょう。ライブラリ関数は新しいライブラリを宣言します。次に、ライブラリを作成するときに、initメソッドはdocument.readyで自動的に実行されます。
function library（module）{$（function（）{if（module.init）{module.init（）;}}）; return module;} var mylibrary = library（function（）{return {init：function（）{ /*実装* /};}（}（））;オブジェクトセルフフェイスサイズ
オブジェクトのセルフフェイス測定はブレースで宣言され、それを使用するときは新しいキーワードは必要ありません。モジュール内の属性フィールドのパブリック/プライベートについてあまり気にしない場合は、この方法を使用できますが、この方法はJSONとは異なることに注意してください。オブジェクトセルフフェイスサイズ：var item = {name： "tom"、value：123} json：var item = {"name"： "tom"、 "value"：123}。
var mymodule = {myproperty： 'somevalue'、//オブジェクトリテラルには、プロパティとメソッドが含まれます。 //ここで、別のオブジェクトは構成のために定義されています}、//現在の構成に基づいて値を出力mymethod2：function（）{console.log（ 'キャッシュIS：' +（this.myconfig.usecaching）？ 'enabled'： 'disabled'）; }、//現在の構成mymethod3：function（newconfig）{if（typeof newconfig == 'object'）{this.myconfig = newConfig; console.log（this.myconfig.language）; }}}; mymodule.mymethod（）; // functionalitymymodule.mymethod2（）; // outputs enabledmymodule.mymethod3（{言語： 'fr'、usecaching：false}）; // frcommonjs
ここでCommonJSの導入については話しません。多くの記事が以前に紹介しています。ここで言及したいのは、2つの重要なパラメーターのエクスポートがあり、CommonJS標準に必要なことです。エクスポートはロードされるモジュールを表し、これらのロードされたモジュールが他のモジュールに依存する必要があり、ロードする必要があることを意味します。
/*標準のCommonJSモジュール形式の周りにボイラープレートを配置することにより、AMDおよび標準CommonJSとの互換性を達成する例：*/（function（define）{define（requent（require、exports）{//モジュールコンテンツvar dep1 = require（ "dep1"）; exports.someexportedfunction = function（）{...} define == "function"？define：function（factory）{factory（require、exports）}）;多くのCommonJS標準モジュールの読み込み実装があります。私が好むのはrequirejsです。モジュールと関連する依存性モジュールを非常にうまくロードできますか？簡単な例を見てみましょう。たとえば、画像をASCIIコードに変換する必要がある場合は、最初にエンコーダモジュールをロードしてから、そのencodetoASCIIメソッドを取得します。理論的には、コードは次のようにする必要があります。
var encodetoascii = require（ "encoder"）。encodetoascii; exports.encodesomesource = function（）{//他の操作の後、encodetoasciiを呼び出してください}ただし、EncodetoASCII関数はウィンドウオブジェクトに接続するために使用されないため、使用できないため、上記のコードは機能しません。これは、コードの改善が必要なことです。
define（function（require、exports、module）{var encodetoascii = require（ "encoder"）。encodetoascii; exports.encodesomesource = function（）{// process then call call encodetoascii}}）;Commonjsには大きな可能性がありますが、叔父はそれにあまりよく知っていないので、私はそれをあまり紹介しません。
ファサードモード
ファサードモデルは、このモデルのアーキテクチャにおいて重要な役割を占めています。多くのJavaScriptクラスライブラリまたはフレームワークは、このモデルに反映されています。最大の機能は、高レベルのAPIを含めて特定の実装を非表示にすることです。これは、インターフェイスのみを公開することを意味し、内部実装の決定を自分で決定することができます。これは、内部実装コードを簡単に変更および更新できることも意味します。たとえば、今日はjqueryを使用してそれを実装しています。明日、非常に便利なユイを変えたいと思います。
次の例では、多くのプライベートな方法を提供し、外部の世界が内部方法を実行および呼び出すことができるように、単純なAPIを公開することがわかります。
var module =（function（）{var _private = {i：5、get：function（）{console.log（ 'current value：' + this.i）;}、set：function（this.i = val;}、run：function（）{console.log（ 'running'）;}、jums（ 'console.（' console.（ 'console.（' jumping）; function（args）{_private.set（args.val）;ファサードと以下で話していることの違いは、ファサードが既存の機能のみを提供するのに対し、メディエーターは新しい機能を追加できることです。
メディエーターモード
モディエーターについて話す前に、例を挙げましょう。伝説的な塔である空港飛行制御システムには、絶対的な力があります。航空機の離陸時間と場所を制御できます。航空機と航空機は以前に通信することを許可されていません。つまり、塔は空港の中心であり、調停者はこの塔に相当します。
メディエーターは、プログラムに複数のモジュールを持つために使用され、各モジュールに依存関係を持たせたくない場合、メディエーターモードは集中制御の目的を達成できます。実際のシナリオでは、メディエーターはやりたくない多くのモジュールをカプセル化し、メディエーターを介して接続することができ、またゆるく結合して、メディエーターを介して通信する必要があります。
では、メディエーターモードの利点は何ですか？それはデカップリングです。以前にオブザーバーパターンをよく理解している場合、以下のメディエーター図を理解することは比較的簡単です。次の図は、高レベルのメディエーターパターン図です。
考えてみてください。各モジュールは出版社であり、メディエーターは出版社であり加入者でもあります。
モジュール1は実際のことを調停者に放送し、何かをする必要があると言って
メディエーターがメッセージをキャプチャしたら、メッセージを処理するために使用する必要があるモジュール2をすぐに開始します。モジュール2処理が完了したら、情報をメディエーターに返します。
同時に、Mediatorはモジュール3を起動し、モジュール2の返品メッセージを受信するとモジュール3に自動的にログを記録します。
モジュール間に通信がないことがわかります。さらに、メディエーターは各モジュールのステータスを監視する機能を実装することもできます。たとえば、モジュール3にエラーがある場合、メディエーターは一時的に他のモジュールのみを必要とし、モジュール3を再起動してから実行し続けることができます。
振り返ってみると、メディエーターの利点は、ゆるく結合されたモジュールが同じメディエーターによって制御されていることがあることがわかります。モジュールは、イベントをブロードキャストして聴くだけで、モジュール間の直接接続は必要ありません。さらに、複数のモジュールを一度に情報の処理に使用できます。これにより、将来の既存の制御ロジックに新しいモジュールを追加できるようになります。
すべてのモジュールが直接通信できないため、すべての比較的パフォーマンスがわずかに低下する可能性があることは確かですが、それだけの価値があると思います。
上記の説明に基づいて、簡単なデモを使用しましょう。
var mediator =（function（）{var subscribe = function（channel、fn）{if（！mediator.channels [channel]）mediator.channels [channels] = []; mediator.channels [channels] .push（{context：this、callback：fn}）; return this;} array.prototype.slice.call（1）;購読：function（obj）{subscribe = subj.publish =};次に、次の2つのモジュールがあります。
// PUB/SUB集中メディエーターMediator.name = "tim"; mediator.subscribe（ 'namechange'、function（arg）{console.log（this.name）; this.name = arg; console.log（this.name）;}）; mediator.publish（ 'namechange'、 'david'）; //ティム、デビッド//サードパーティのメディエーターvar obj = {name： 'sam'}; mediator.installto（obj）; obj.subscribe（ 'namechange'、function（arg）{console.log（this.name）; this.name = name = arg.log; log（this.name）;}）; obj.publish（ 'namechange'、 'john'）; //サム、ジョンアプリケーションファサード：アプリケーションのコアの抽象化
ファサードは、アプリケーションコアの要約として機能し、メディエーターとモジュール間の通信を担当します。各モジュールは、このファサードを介してプログラムコアとのみ通信できます。要約としての責任は、これらのモジュールにいつでも一貫したインターフェイスを提供できることを保証することです。これは、Sendboxコントローラーの役割に似ています。すべてのモジュールコンポーネントはメディエーターと通信しているため、ファサードは信頼できる信頼できる必要があります。同時に、モジュールにインターフェイスを提供する関数として、ファサードは別の役割、つまりセキュリティ制御、つまりプログラムのどの部分にモジュールでアクセスできるかを決定する必要があります。モジュールコンポーネントは独自のメソッドのみを呼び出すことができ、不正なコンテンツにアクセスできません。たとえば、モジュールはDataValidationCompletedWriteToDBをブロードキャストする場合があります。ここでは、セキュリティチェックがデータベースに許可を書き込むことを保証する必要があります。
要するに、メディエーターは、ファサード許可検出後にのみ情報処理を実行できます。
アプリケーションメディエーター：アプリケーションのコア
メディエーターは、アプリケーションの中心的な役割として機能します。彼の責任について簡単に話しましょう。最もコアの仕事は、モジュールのライフサイクルを管理することです。このコアが情報をキャプチャする場合、プログラムがどのように処理するか、つまり、どのモジュールが起動または停止するかを決定する必要があります。モジュールが起動すると、アプリケーションコアが実行されるかどうかを決定するために自動的に実行できるはずです（たとえば、DOMの準備ができたら実行する必要があるかどうか）。モジュール自体を決定する必要があります。
モジュールはどのような状況で停止しますか？プログラムがモジュールが故障したりエラーを犯したりすることを検出すると、プログラムは、ユーザーエクスペリエンスを改善する主な目的で、モジュール内のメソッドの実行を継続しないように決定する必要があります。
さらに、コアは、他の機能に影響を与えることなく、モジュールを動的に追加または削除できる必要があります。一般的な例は、ページの読み込みの先頭にモジュールが利用できないことですが、ユーザーが動作した後、モジュールを動的にロードして実行する必要があることです。 Gmailのチャット機能と同様に、パフォーマンスの最適化の目的から簡単に理解できるはずです。
例外エラー処理は、アプリケーションコアによっても処理されます。さらに、各モジュールが情報をブロードキャストすると、プログラムコアが状況に応じてこれらのモジュールを停止/再起動できるように、コアにエラーをブロードキャストします。これは、ゆるく結合されたアーキテクチャの非常に重要な部分でもあります。モジュールを手動で変更する必要はありません。調停者を介してパブリッシュ/サブスクライブを使用してこれを行うことができます。
組み立てる
各モジュールには、プログラムにさまざまな機能が含まれています。処理する情報がある場合、プログラムに通知する情報を発行します（これが主な責任です）。次のQAセクションでは、モジュールは一部のDOMツール操作方法に依存できるが、システムの他のモジュールに依存してはならないと述べた。モジュールは、次のコンテンツに注意を払ってはいけません。
1.どのオブジェクトまたはモジュールがこのモジュールによって公開された情報に登録します
2。これらのオブジェクトはクライアントまたはサーバー側のオブジェクトです
3.情報を購読しているオブジェクトの数
ファサード抽象化アプリケーションのコアは、モジュール間の直接通信を回避します。各モジュールからの情報を購読し、認証検出についても責任を負い、各モジュールに独自の承認があることを確認します。
Mediator（Application Core）は、Mediator Modeを使用して、モジュール管理とSTART/STOPモジュールの実行を担当するPublish/Subscribe Managerの役割を再生し、モジュールをエラーで動的にロードおよび再起動できます。
このアーキテクチャの結果は、モジュール間に依存関係がないため、緩やかに結合されたアプリケーションのために、簡単にテストおよび維持できます。各モジュールは、他のプロジェクトで簡単に再利用でき、プログラムに影響を与えることなく動的に追加および削除できます。
パブ/サブエクステンションの公開：自動イベント登録
イベントの自動登録に関しては、特定の命名仕様に従う必要があります。たとえば、モジュールがMessageUpDateという名前のイベントを公開する場合、MessageUpDateメソッドを持つすべてのモジュールが自動的に実行されます。利点と利点と短所があります。具体的な実装方法については、私からの別の投稿を見ることができます：jqueryカスタムバインディングのマジックアップグレードバージョン。
Qa
1.ファサードまたは同様のサンドボックスモードを使用しないことは可能ですか？
アーキテクチャの概要は、ファサードが認証チェック機能を実装できることを提案していますが、実際にはメディエーターがそれを行うことができることは完全に可能です。ライトアーキテクチャが行う必要があることは、ほぼ同じです。つまり、各モジュールがアプリケーションのコアと直接通信することを分離して保証することです。
2。モジュールが直接依存できないことを改善しました。それは、サードパーティライブラリ（jqueryなど）に依存できないことを意味しますか？
これは実際には両側の問題です。上記のように、モジュールにはいくつかのサブモジュール、または基本的なDOM操作ツールクラスなどの基本モジュールがある場合があります。このレベルでは、サードパーティライブラリを使用できますが、簡単に交換できることを確認してください。
3.私はこのアーキテクチャが好きで、このアーキテクチャの使用を開始したいと考えています。参照に使用できるコードサンプルはありますか？
参照用のコードサンプルを作成する予定ですが、その前に、Andrew Burgeesの投稿執筆モジュラーJavaScriptを参照できます。
4.モジュールがアプリケーションコアと直接通信する必要がある場合、それは実行可能ですか？
技術的には、モジュールがアプリケーションコアと直接通信できない理由はありませんが、ほとんどのアプリケーションエクスペリエンスでは、まだ許可されていません。このアーキテクチャを選択したため、アーキテクチャによって定義されたルールを順守する必要があります。
謝辞
元の投稿をしてくれたニコラス・ザカスに、アイデアをまとめて、テクニカルレビューのためにアンドリー・ハンスソンに、レベッカ・マーフィー、ジャスティン・マイヤー、ジョン・ハン、ピーター・ミシェー、ポール・アイリッシュ、アレックス・セクストンに感謝します。