単純なモデルとビューのみの代わりに MVC を使用することが有利である理由の例を誰でも挙げることができます。
注: MVC と呼ばれるか MVP (Model-View-Presenter) と呼ばれるかに関係なく、View が入力を受け取るものについて話していると、Controller は入力を解釈して入力イベントに応答し、モデル。モデルが変更されると、ビューはモデルからのイベントに応答して更新されます。
モデルをビューのイベントに応答させたり、その逆をさせたりすることの不利な点は何ですか?
MVC では、コントローラーに影響する方法でモデルを変更した場合、コントローラーで変更を行う必要があります。モデル ビューでは、モデルを変更すると、ビューを更新する必要があります。
それで、「コントローラー」部分を追加することで複雑さを導入しているように見えますか?
MVC では、モデルはその環境に対して盲目であり、ビューもそうである可能性があります。ビューとモデルについて詳しく知っているコントローラーに (盲目的に) イベントを渡します。結局のところ、コントローラーはシステムの「再利用不可能な」使い捨て部分です。これは、最もコンテキストを意識したコンポーネントであるためです。
コントローラーに影響を与えるような方法でモデルを変更した場合...
モデルは、単純な CRUD メソッドを公開する必要があります。メソッドを使用する人は、渡された更新オブジェクトについて何も知らなくても、モデル内で実際に何が起こっているのかを知る必要はありません。
これは、コントローラはステートレスであると想定されており、ビューはより永続的であるため、渡されたレコードを作成することにより、ビュー IMO が少し作業を行う必要があることを意味します。コントローラーはトリガーされ、「キックイン」は渡されたオブジェクトで作業を行い、状態はありません。
渡されたデータは、ある種の一般的な規則によって作成されます。
さらに行かせてください。ビュー、テーブルグリッド、および有効なプロパティがグリッドで選択されているアイテムに依存するコントロールがあるとします。これらのコントロールとこのロジックの両方を内部で処理するビューを作成できます。このような単純化された例では。
しかし、ビューがよりアトミックになればなるほど、ビューはより再利用可能になるため、すべての、はいすべてのコントロールに対してビューを作成します。今、正しい通知のために自分自身を登録するために、ビューがお互いを知る必要がある状況を見ています...
ここでコントローラーが介入します。これは、これらすべての依存関係をコントローラーに固執させたいためであり、長期的には使い捨てです。そのため、コントローラーはこのタイプのビューからビューへの通知スキームを管理します。
これで、ビューは無知になり、独立しているため、再利用可能になります。
システムや、いわゆる「ビジネス ロジック」について知らなくても、ビューをコーディングできます。目標についてあまり知らなくてもモデルをコーディングできます (ただし、モデルを微調整して、念頭に置いているデータセットを返すことができるようにすることは役立ちます)。物事を一緒に配線する前に、前の 2 つが固まりました。
もう 1 つ考慮すべき点があります。ちょうどモデルが抽象化され、管理しているデータの基礎となる実装への汎用インターフェイスを提供することになっているのと同じです (クライアントは、データが DB、ファイルから来ているかどうかを知りません)。 、プログラム設定など) -- ビューは、使用しているコントロールも抽象化する必要があります。
したがって、最終的にこれは、ビューが次のような関数/プロパティを持つべきではないことを意味します (以下の警告)。
public property BackgroundColor{get;set}
または
public function ScrollBy(x,y){}
代わりに：
public SetProp(string name, object val){}
と
public DoCmd(string name, object val){}
これは少し不自然で、最終的に言ったことを思い出してください...そして、なぜこれが良い考えなのかと尋ねますか?
再利用性を念頭に置いて、いつの日か WinForms から Flex などに移植したり、同じ機能を公開していない可能性のある新しい制御ライブラリを単純に使用したいと考えるかもしれません。
ここで「移植」と言いますが、それは実際の目標ではありません。この特定のアプリを移植することには関心がありませんが、基礎となる MVC 要素を新しいフレーバーに引き継ぐのに十分な汎用性を持たせる必要があります。 -独立した外部インターフェースはそのまま。
これを行っていない場合は、新しいフレーバーが登場したときに、(潜在的に再利用可能/リファクタリング可能/拡張可能な) コントローラーのビュー プロパティへのすべてのハード参照をいじる必要があります。
これは、そのような汎用セッターとコマンドがすべてのビュー機能のインターフェイスでなければならないという意味ではありませんが、従来のハードリンク方法で公開できる通常の props/cmd だけでなく、「エッジ ケース」プロパティも処理する必要があります。 . 「拡張プロパティ」ハンドラと考えてください。
そのようにして、(再び工夫して) ボタンに buttonIcon プロパティがなくなったフレームワークを構築しているとします。buttonIcon が拡張プロパティであるボタン ビュー インターフェイスを作成するという先見の明があり、ビュー内では、set/get を受け取ったときに条件付きコードがノーオペレーションを実行するため、これはすばらしいことです。
要約すると、MVC のコーディングの目標は、Model と View の一般的なインターフェイスをその基になるコンポーネントに与えることであるべきだと言いたいのです。 . そして、コントローラーが (一見不当に) 長期的な再利用性の犠牲子羊になるように設定されていますが、これは、すべてのコントローラーが死ぬ運命にあるという意味ではありません。
多くの「思考」がセミインテリジェントなモデルとビュー、およびその他のコントローラー (例: グリッドを並べ替えたり、TreeView を操作するコントローラー) に押し込まれたため、それらは小さいことを願っています。で、次のプロジェクトで再利用する資格があります。または、適切になるように複製して微調整します。
ワークフローロジックをドメインロジックから分離することにより、実際には複雑さを軽減します。また、単体テストの作成が容易になり、アプリケーションの保守と拡張が容易になります。
新しいデータ型を追加したい場合を想像してみてください。上記のアプローチでは、ドメインロジックに緊密に結合されている可能性が高いため、新しいクラスでワークフローロジックの多くを複製する可能性があります。
ワークフローロジックをコントローラーに分離することに関連する規律により、ワークフローとドメインロジック間の依存関係が少なくなる可能性が高くなります。新しいデータ型の追加はより簡単になります。新しいドメインオブジェクトを作成し、コントローラーのスーパークラスから継承するなどして再利用できるコントローラーの量を確認します。
また、将来的にフレームワークを変更するのも簡単になります。モデルはおそらくあまり変更されないため、移植性が高くなります。
そうは言っても、プレゼンテーション層として使用しているものに応じて、MVVMを調べたいと思うかもしれません：MVCに対するMVVMの利点
MV に対する MVC/P (ここでは監視コントローラーについて話している) の利点は次のとおりです。
必要に応じて、コントローラーで複雑なデータ バインディング コードを処理できます。
UI テスト フレームワークがなくても、その複雑なプレゼンテーション ロジックをテストできます。
また、グラフィック デザイナーにビューを作成してもらい、コードを表示せず、ビューを修正するときにコードを台無しにしないようにすることもできます。