ThedricWalkerの答えに基づいて...
これ、おそらくばかげた、アナロジーを取ります:
あなたはキツツキ(モジュール)であり、家の支持構造(コア)に置かれている幼虫(データ)をいくつか選びたいと思っています。通常は、インフラストラクチャから幼虫をつつくだけです(実際には、キツツキは頭蓋骨を包む長いとげのある舌を持っています)が、一部の大工(アプリケーションアーキテクト)は家の外にファサードを適用しました。しかし、大工はキツツキだけが幼虫にアクセスできるようにファサードに穴を開けるのに十分素晴らしかった。さらに、大工はこれらの穴を特定の形にするのに十分賢いので、キツツキはペックごとにより多くの幼虫を食べる作業を行うことができました。
では、なぜファサードがあるのでしょうか。
ファサードをAddyの投稿に関連付ける-ファサードは、サンドボックスが事前定義された有効性を提供し、1つのモジュールが特定の方法(卸売など)でタスクを実行できるようにするという点で、サンドボックスを強化します。たとえば、ユーザーに次の書き込みを強制するサンドボックスは必要ありません。
var node = getNode('#errorPanel');
node.innerHTML = 'Field is invalid!';
より良いサンドボックスには、次のようなものがあります。
notifyUser.error('Field is invalid!');
一方、ファサードは、チャンネルを聞くだけで、同じようにそれらの通路を提供できますmediator.fire('error:Validation', 'Field is invalid!')
。
私がいつも使用しているAddyの投稿のファサードは、理論的には単純にリクエストをコアに転送することができます。おそらく、チャンネルの信号の何かをチェックして、たとえば、フィンチが病気になる幼虫をつついたりしていないことを確認します。たとえば、例外をスローします。
これが、コアに個別のチャネルメディア(つまりメディエーター)を用意することが理にかなっている理由です。ここで、ファサードはコアへの唯一の「参照」であり、モジュールはファサードのみを参照します。もう1つの方法は、チーム内で離散チャネル名の規則を適用することです(例:mediator.fire('ready://Core')
& ) mediator.fire('updated://ToDos/task', taskId)
。はfacade
リッスンし'updated://ToDos/task'
、-にリクエストを送信しcore
ます。これは次のようになります。
var thus = mediator.installTo(this);
this.on('updated://ToDos/task', function(id){
thus.fire('request://Core/save/todo', id);
thus.fire('user://Core/notify/task/added', id);
});
this.on('response://Core/save/todo', function(err, id){
if(!err){
// ... success -- notify module!
} else {
// ... notify for failure :(
}
});
注意!リスナー呼び出し内にハンドラーを直接記述しないでください。
これがお役に立てば幸いです。鳥について話すことに反対票を投じないでください; )