モデル - >オブザーバー - >ビュー - >コントローラー - >モデル - >

Question

私はデザインパターンを読んでいて、オブザーバーパターンはクールであると同意しますが、デザインに関しては、

私はちょっと混乱しています、MVCダイアグラムは円形ではありません、コードフローが閉じたトポロジーを持つのは自然ではありませんか？なぜこのパターンを話す人がいないのですか：

model -> observer -> view -> listener -> model -> .. 

ビューにコントローラが必要な場合は、オブザーバが必要ですか？次のJavaScriptバージョンでObject.observe（）を呼び出すと、このようなパターンで何が問題になりますか？

Answer 1

ビューとコントローラは両方ともオブザーバーです。

モデル上のイベントのビュー/オブザーバ/オブザーバ。コントローラーは、ビュー内のイベントのオブザーバーです。コントローラはモデルのコマンドを起動し、その状態を変更して、状態が適切に変化するビューによって観察されるイベントを伝播させます。

解決しようとしている問題は、モデルの変更にUIが応答し、モデルがUIを介してユーザーからの入力に応答することです。人間の視界の脆弱さ以外に、第3のコンポーネントを関与させる大きな理由はありません。イベント駆動システムよりもコマンドと制御システムを想像するほうがはるかに簡単です。

提案されたデザインの1つの問題は、懸念の分離です。 MVC（メッセージ/イベントで正常に実行された場合）では、各コンポーネントは自分自身とそれ自身の懸念事項を知っています。あなたが提案しているモデルでは、Observerコンポーネントはビューのオーケストレーション方法を知っていなければなりません。

もちろん、コントローラーがモデルの変更を調整すると考えているので、関係の遠い側に同等のコンポーネントがないのはなぜですか？

実際には、「コントローラ」スペースに何かを実装していますが、メッセージ/イベント/コマンドをビューからモデルに渡すのはしばしば「インフラストラクチャ」です。コントローラはシンプルなルータに移行します。オーケストレーション・コンポーネントの必要性は、現代デザインでは、DDDと集約ルート・パターンの理解が深まり、もちろんイベント・ソーシングの可能性が減っているため、削減されました。

最後に、あなたが言及しているパターンは、もともとはギャングオブフォーに実際に存在し、比較的一般的なものとして文書化されていました。当時、モバイルアプリケーションやWebアプリケーションはなく、最大のシステムの1つはgimpでした。私たちの技術が成熟し、私たちのアプリは複数のチャンネルを介して配信されるので、このスペースでの開発のパターンがあります。数年前、私たちはMVC2について議論していました。そして、私たちはMVVCやMMVCのような奇妙なものに移りました。さて、CQRS、イベントソーシング、およびDDDを使用して、オーケストレーションのアプローチが限界を示し始め、イベント駆動型システムが前面に出現するにつれて、MVについて語り始めました。