したがって、通常、MVC を操作する場合は、入力を制御するコントローラーを使用して、入力を処理し、ユーザーが使用できるようにするモデルと、ユーザーに「結果」を表示するビューを用意します。
このパターンを作成するときは、コードを関連する場所に分けます。たとえば、コントローラ コードはコントローラに入り、GUI コードはビューに入ります。
ここで私の質問は、たとえばオブザーバー パターンなど、そこにあるすべてのデザイン パターンを調べるかどうかです。MVC パターンを既に実装しているコード構造に、そのようなパターンをどのように適用しますか? その場合、コンポジット、ファクトリー、コマンドパターンなど、他の多くのパターンはありますか?
MVC パターンの構造が、他の優れたデザイン パターンの実装を難しくしていませんか?
MVC では、オブザーバー パターンを使用して、モデルのさまざまな要素間の通信を調整できます。
たとえば、1 つのコア モデル コンポーネントがデータを生成し、他のモデル コンポーネントに通知する必要があるとします。他のモデルをコア モデルのリスナーとして登録することで、この通信を容易にすることができます。
この動作は、ビューおよびコントローラー層で発生するものとは無関係です。
ビューに他のパターンを含めることができます。たとえば、メディエーター パターンを使用して、javascript 内のモジュールまたはビュー間で通信できます。オブザーバー パターンも使用できます。
これは、サンドボックス パターンの使用方法に関する Nicholas Zakas によるプレゼンテーションのビデオです。これはメディエータ パターンに非常に似ていますが、もう少し複雑で、さらに疎結合のモジュールを作成できます。http://www.youtube.com/watch?v=7BGvy-S-Iag
これは、mvc パターンを使用しながら JavaScript で実装できます。たとえば、Rails でこれを使用すると、慣例により自然に mvc が強制されます。
編集: 技術的には、Rails は MVC ではありませんが、アイデアはわかります。詳細については、Ruby on Rails の MVC とは?
いいえ。他のオブジェクト指向および関数型プログラミング パターンを否定するものではありません。
MVC は、コードを管理しやすくするために純粋な OOP プラクティスでは不十分な場合に、既存のコードベースの上に使用するアーキテクチャ設計パターンです。
MVC パターンは追加の制約を導入し、コードとコードのパーツ間の情報の流れを整理できるようにします。