教材

特徴

ビジュアル表示に関する処理とユーザー インターフェイスの状態や動作に関する処理をそれぞれ個別のクラス (ビューとプレゼンテーション モデル) で行います。

プレゼンテーションモデルはユーザーインターフェイスの状態を持ちます。
また動作も持ちます。分割方針は、ほぼMVVMと一緒です。
（そも、MVVMは、Presentation Modelの派生という認識です。）

プレゼンテーション モデル クラスは、モデルへのアクセスをカプセル化して、ビューから簡単に使用できるパブリック インターフェイスを提供する

ビューが更新するのはプレゼンテーションモデルです。
モデルを直接更新しません。次のような役割と考えられます。

MVCで扱いに困る、コントローラー内の「モデルを更新するか、モデルを更新せずにビューだけ更新する」ロジックはプレゼンテーションロジックに定義できます。

プレゼンテーション モデルはモデルの更新、照会、監視を行います。また、ビジュアルコンテンツ内の変更をビューに通知します。

プレゼンテーションモデルはモデルを監視し、状態を自身に反映し、ビューに変更を通知します。
プレゼンテーションモデルにテスト用のドライバーをつければ、プレゼンテーションモデルの状態管理をテストできます。

データ バインドは、一般に、サーバーまたはローカルの構成データをフォームやその他の UI コントロールに配置して使用します。

Microsoft AccessでDataGridにデータベースをつないで表示、編集する世界観の延長です。
データベースを他のモデルに拡張するためにプレゼンテーションモデルで抽象化します。

分け方に違いはありません。
原始MVCのコントローラーは以下の役割を持ちます。

プレゼンテーションモデルの役割と一致します。

MVCでは「モデルと関わらないビューの状態管理」はモデルには入りません。
なぜならMVCでは次の手順で役割を分けます

「モデルと関わらないビューの状態」はビジネスロジックではありません。
つまりモデルではありません。

The Model-View-Controller (MVC) Its Past and Presentでは、別のパターンとして紹介されています。

メリット：「モデルと関わらないビューの状態管理」がテスト可能に
デメリット：プレゼンテーションモデルとモデルで状態を二重管理

モデルからプレゼンテーションモデルへの状態反映が自動化できれば、ノーコストで「テスト可能なビューの状態」が手に入ります。

（現実の歴史では、絵に描いた餅になります。）