僕が心の中でやっているMV*パターン分類方法

クライアントサイドの設計パターンには、MVCの派生の MVP 、MVVM の名前をよく聞きますね。

いろいろな実装が、どのパターンにあたるか分類することは、意外と微妙で、明確にすることにはあまり意味がなく不毛という話も聞きます。たしかに、々なGUIプログラミング環境を見ていくと、実装上の制限や事情の違いがあり、比較するのは無理があるかもしれません。

個人的な考えでは、MV* な設計パターンは、とくに難しい話ではないと思います。元々は.NET方面で MVC → MVP → MVVM の順に時系列に進化したものだったと思いますが、意外と他の環境でも同じ言葉を当てはめて有用だったからややこしいのかなと思います。

それぞれ、中心とする要素が違っているので、それに注目していくと意義とかが見えてきます。

MVC

MVCの中心は Model。Model を直接、Viewが監視する。

古典的なMVC は、View が Model の 直接のオブザーバになります。Controller は入力を受けつけるのが役割です。つまり、Controller のコントロールの主語は ユーザなんですね。ユーザ視点での、アプリケーション全体のインターフェイスみたいな意味合いというわけです。テレビとかエアコンでいうところのリモコン

現在では、狭義の意味でのMVCはほぼ見られないと思います。

MVP

MVPの中心は Presenter。 MとVの間をとりもつ。

Modelが変更されたら自動でViewが変更されるというのは理屈はきれいですが、現実にはViewはたくさんのパーツの集まりだし、ViewとModelのバインディングが複雑だったり、そもそもドメインロジックに非同期処理などが絡んでくると、Modelの変更タイミングとViewの変更タイミングの制御が煩雑になったりりします。

そこで、ModelとViewの間に立つ人を立てたのがMVPです。P はPresenterで、間に立つ人です。
割とふつうです。iOS には 標準でViewControllerというものがありますが、あれはほとんどPresenterだと思います。

MVVM

MVVMの中心は ViewModel です。

ViewModel は、UIの状態をすべて表現できる構造体です。これを操作することが、MVVMでアプリケーションを書く作業の心臓部です。

なんでそんな構造体を間に介して冗長にならないかというと、データバインディングが前提になっているからです。

MVVMは、データがViewでどう表現されるか宣言的に記述できる方法がないと普通はそう呼ばれません。
だから、js界隈とかで、独自HTMLテンプレにDSLを埋める=MVVM とか呼ばれたりしています。
リアクティブプログラミングとかの仕組みも、宣言的にバインディングが書けるのでMVVMみたいな設計にしやすいです。

そんなかんじです。