MVCアーキテクチャのウィキペディアページによると、ビューはモデルから通知されることも、モデルの現在の状態についてクエリすることもできます。ただし、スタンフォード大学のiOS 5のPaul Hegartyのコース1、18ページによると、すべてのやり取りはコントローラーを介して行われる必要があります。ヘガティの声明がコースの簡略化を意図したものであるかどうかは私には明らかではありませんが、私は彼がそのようなデザインを意図していると言いたくなります。
これら2つの反対の視点をどのように説明しますか？
回答:
これは、MVC / MVVMで議論のあるトピックです。ビューからモデルに直接アクセスしても問題ないと言う人もいれば、ビューから抽象化するためにモデルをViewModelsにラップする必要があると言う人もいます。私は個人的にどちらのアプローチのファンでもありません。
MVC / MVVMの主要な目標の1つは、UI、ビジネスロジック、およびデータを分離することです。したがって、その概念を念頭に置いて、ビューがモデルに直接アクセスできるようにすると、必要のない依存関係が作成されます。一方、ViewModelsはモデルへのパススルーとして機能する傾向があるため、ViewModelsでモデルをラップするのは面倒であまり役に立ちません。
Modelsに特定のインターフェイスを実装させるアプローチが好きなので、IModelと呼びます。ViewModelクラスは、Viewの消費のためにIModelを実装するオブジェクトのインスタンスを提供できます。ビューは、ViewModelから取得したIModelオブジェクトで機能することを単に認識しています。これにより、無関係なViewModelラッパーコードが削除され、IModelの具体的な実装がビューから非表示になります。ビューに少し影響を与えることなく、後でIModelの実装を別の実装に交換できます。
ウェブでは、誰もがデカップリングMVCと呼んでいます。
C＃などの一部のテクノロジーはMVVMを使用します。これは、ビューと他のオブジェクトとの間にリンクがなく、すべてがサービスロケーターを通過して変数をバインドするためです。
純粋なMVCでは、ビューはモデルと直接対話し、その逆も同様です。コントローラーは、変更が発生した場合にのみ存在します。
そして、PAC（プレゼンテーション抽象化制御）と呼ばれるものがあります。このアーキテクチャでは、ビューとモデルは互いに対話しません。コントローラは、ビューまたはモデルのいずれかで何かを実行できる唯一のコントローラです。多くの場合、これはMVCと混同されます。
ここでより良い説明が表示されます：http : //www.garfieldtech.com/blog/mvc-vs-pac
ではMVC、ポールHegartyは間違っています。コントローラーは、モデルからビューへの通信ではなく、ユーザーイベントに関するものです。古典的なMVCでは、ビューはモデルを観察します（オブザーバーパターン）。
調停を行う間に、パターンはMVPと呼ばれるべきであり、実際、今日MVCとして提示されているもののほとんどは、実際にはMVPに近いものです。
次に、両方に似ているが、少し異なっており、ずっと前に存在していたMVVMがあります...ビューモデルオブジェクトを介して結合された2つのMVC / MVPとして見るのが最善です-「クライアント」MVCはそのモデル、および「サーバー」MVCにはビューとしてviewmodelがあります。
特にスタンフォード大学の講義の資料について質問しているので、Hegartyのスタンスについて2つのことを検討する価値があります。
私はポール・ヘガティに同意し、ビューはモデルについて知らないはずだと信じています。それを達成するのはそれほど難しくありませんが、設計と将来の柔軟性に追加の利点をもたらします。
「ダミー」のViewModelクラスを避けて物事をシンプルにしたい小さなアプリケーション（通常はデスクトップ）では、IModelインターフェイスも使用し（上記の回答を参照）、ModelがViewを認識しないようにします（サブスクライバーを使用します）古典的なMVCのように）。
また、この場合、コントローラーはビューと完全に連動するようになっています。簡単にするために、必ずしも明確に分離しているわけではありません。
2番目の「単純化された」アプローチは、同じモデルに複数のビューがある場合は問題ありませんが、異なるモデルに同じビューを使用する場合はお勧めしません。異なるとは、メインモデルに「従う」JUnitテストクラスだけでなく、本質的に本当に異なることを意味します。
私は、これに対する厳格で速い規則はない、それはあなたのニーズに完全に依存すると信じています。
あなたは異なる信念を持つ人々を見つけるでしょう。アーキテクチャは、より優れたソリューションの設計を支援する概念です。
モデルビュー通信とは別に、MVCのビジネスロジックについてもう1つの矛盾があります。多くの人々は、すべてのビジネスロジックを1つのモデルにする必要があると考えています（このSOの質問を参照）。
これとは別に、ビジネスロジックをアプリケーションロジック（コントローラーに配置）とドメインログイン（モデルに配置）に分割する可能性があります。
そのため、ストーリーの教訓は、MVCはモデル、ビュー、コントローラーを分離する必要があるということです。それ以外は、あなたに一番合うものは何でも。
モデルビューの通信にDTOを使用しています。
例えば：
ビューとモデルが異なるコンテキストで自由に対話する必要がある理由と方法について多くが提案されていますが、コントローラーを作成するためのiOSの主な理由はそれらの間のメディエーターであり、コードベースのモデルとビューの依存関係を回避し、再利用できるようにすることですiOSの進化に伴い、要件に応じてモデルまたはビューを作成します。
UI / UXまたはモデル、あるいはその両方でアプリの更新を保持する必要がある場合があるため、モデルとビューの間でモード依存コードを生成しないようにする必要があります。アプリのプレゼンテーションレイヤーを変更する場合は、変更すると、同じモデルを再利用でき、その逆も可能です。
iOSのMVCは、さまざまなロジックを多数備えた巨大なViewControllerを作成し、意図したもの以外のあらゆる種類のものを処理することに同意しますが、コードベースをより柔軟で簡単にするために、MVVMまたはPresentation Controlsを使用することをお勧めします小さいViewControllerで読み取り、保守可能。
これは、iOSで小さいViewControllerを探している人に役立つかもしれません。
http://blog.xebia.com/simplification-of-ios-view-controllers-mvvm-or-presentation-controls/