MVC、MVP、MVVM 改め VCM、VPM、VVMMとしたい

なぜM（Model）に来るんだろうか

私はずっと思っていた。なぜ、M（Model）が前に来るんだと。

MVCは「V → C → M」の方が、イベント発火時のデータの流れがわかりやすくないかと。MVPも「V → P →」だし、MVVM も「V → VM → M」じゃないかと。

頭のいい GPT に聞いてみる

トリグヴェ・リーンスカウクっていうノルウェーのコンピューターサイエンティストがつけた名前らしい。オブジェクト指向の研究に精を出している偉いおじさん。

「モデルがあって、それを表示するビューがあって、ユーザー操作をモデルに反映するコントローラーがある」といった具合に、ドメインに対して重要な部分から降りてく感じで、命名されたというか、そのまま定義されたというか。まあ、なんとなく理解できる。

改めてアーキテクチャの概要を

まずは、必ず登場する人物は「View」と「Model」だということを理解する。とすれば、各種 アーキテクチャの違いは、「View」と「Model」を橋渡しする奴らの違いだということがわかる。

MVC

こいつの場合は、橋渡しするやつは「C（Controller）」。なので、Modelを取得・更新したり、Viewの操作をする役割はこいつが担う。

MVP

彼の場合は、橋渡しするやつは「P（Presenter）」。あれ？ Controller と何が違うん？となるかもしれないが、Controller がになってた「Modelを取得・更新したり、Viewの操作をする役割」を担うのは基本的に一緒。違うのは、参照。Controller と違って、View とベタベタと仲良くせずに、protocol っていう、情緒を重んじない役所の窓口みたいな、抽象化したインターフェースを介して View とやりとりするので、疎結合にすることができる。疎結合にすることで、テストしやすい、修正しやすいっていうメリットがある。

MVVM

彼女の場合は、橋渡しするやつは「VM（ViewModel）」。あれ？Presenterと何が違うと思うかもしれないが、その明確な違いは「データバインディング」っていう、仕組みがあること。双方向データバインディンって言ったりする人もいるけど、要は、Presenter で行ってた protocol による役所窓口の役割を、この「データバインディング」がになってるってこと。Swift だと前は RxSwift っていうライブラリを使って、このデータバインディングの機能をお借りしてたけど、最近だと「Combine」っていう、Apple様純正のフレームワークが登場している。なんか、Apple様が作ったので、システム全体に関わる根幹として、フレームワークって呼んでたけど、RxSwift はライブラリって呼んじゃったのが可哀想になってきた。

それぞれのメリットデメリットの所感

まずはMVCさんは、残念ながら論外。Viewの描画やら、データの取得やら更新やら、全てこのクラスに定義すると、読みづらいし、テストしずらいし、なんかいけてない。

MVPさんは、あり。だってテストしやすいし、Delegateパターンで実装されている Apple 様のコードも多いからね。まあ、ボイラープレートが増えて冗長化なコードになっちゃう感はあるけど、そこまで私は気にしない。

MVVM さんも、MVP 同様に依存がない（protocolを参照してる）ので、ViewModelをテストしやすいよね。いい人。Viewも基本的にViewModelから渡された値を「あ、はい」って言って表示するだけなので、シンプルになるよね。

まあ、簡単かつ短期間ものだったらMVC。TDD（テスト駆動開発）とか、テストをちゃんとやりつつ開発するとか、RxとかCombineとかの勉強が厳しいなら MVP。あとは〜まあMVVMでいいんじゃね？っていいう。SwiftUIとCombineとの親和性もそうだし。Apple様からの圧力を感じるので！

最後に

これは、久しぶりに iOS を触ったエンジニアが、当時の記憶を読み起こすべく、適当に書いた記事です。それぞれ、細かな？というか、大きな違いなどはもっとありますので、なんとなくのイメージを掴むものとしてみてくださいっ！