はじめに
ぽえむ。
こんな風に考えていた時期が、私にありました系アンチパターン。
鵜呑みにするとひどい目に合う(一敗)。
Windows FormsのVBを例にとってる。
MとVとVM
- M：Modelの事。ロジックとか。
- V：Viewの事。入出力系。I/Oをひとまとめにしたもの。
- Input：モニターに映る入力項目とか、洗濯機にあるボタンとか、冷蔵庫の温度センサとか。人間の耳とか。
- Output：モニターに映るGUIとかCUIとか。あとはLEDとかタイヤへのトルクとか。音とか。
- VM：Viewを持つModelの事。つまり特殊なModel。Viewの概念モデル。ヘッドレスビューと言ってもいいかも。
昔のMとVとVMのファイルの関係
昔はデザインなんか凝れなかったのでVMのForm.vbを、Vが奪う必要が無かった。
使う人も限られていたのでデザインよりシステム優先だった。
- V：Form.resxの事。
- VM：Form.Designer.vbとForm.vbの事(今だと違う。Vに取られた為)。
- M：上記以外のHoge.vbとかの事。
今のMとVとVMのファイルの関係
PCのパワーに余裕が出てきた。ソフトもデザインがモノをいうようになった。
一般人もソフトウェア産業経済に入り、ソフトウェアの差別化もありデザイン優先になった。
- V：Form.resxとForm.Designer.vbとForm.vbの事。
- VM：FormViewModel.vbの事(名前はテキトー)。
- M：上記以外のHoge.vbとかの事。
昔のMとVとVMの関係
もともとVMはVのモデルなので、VはVMの振る舞いに追従するように設計されていた。
VMがCloseと言えばVは消えるし、VMがHideと言えばVは非表示になる。
VMがShowと言えば表示されるし、Vから来たCloseイベントも、VMの意思によってそのままCloseさせたり、させなかったりしてきた。
デカい処理はMに投げ、結果を受け取ったVMはDesignerに反映することでVがその通りにふるまった。
VMの振る舞い、状態を、VがPCのモニターに表示していた。
ヘッドレスにテストするときも、単にVを表示しなければ良い為、Vが結合した状態でも何ら問題はなかった。
当たり前のようにVMはVを知っており、Vには処理的権限がなかった。
今のMとVとVMの関係
デザイナーが跋扈した。
デザイナーはまずVMの場所(Form.Designer.vbとForm.vb)を奪った。
プログラマがVMとして使うと、Vが動かないからだ。
VMの場所でVの制御をしない場合でも、デザイン確認(動作確認)のため、完全にVMからプログラマを追いやった。
かつてのVMを奪われたプログラマは、仕方なく別の場所にVM（FormViewModel.vb）を作ることにした。
Vとの結合時はbindすることで対応することにした。
もともと大半がヘッドレスなテストだった為、VMだけでもテストはできた。
ダミーのVを用意すればVありのテストもできた。
もっと今のMとVとVMの関係
そのソフトの性質が許す限り、Mをサーバーに置くことで、Mを分離した。
様々なViewの基底となるものが増えてきた。
従来のOSと入出力機器はもちろん、タッチ操作がメインのスマホ、web、API、IOT機器。
これらViewが（データリンク層の）イーサネットと、TCP/IP(あとUDPとか)を通して、
当たり前のように高速かつ大容量の通信をするようになった。
ソフトをマルチプラットフォームに展開でMをAPI化することで、
ある程度再利用しつつ追従できるようになった。
そんなことしなくてもweb一本化が一番再利用性高いと思います。
なぜかクライアントのネイティブアプリへのこだわりが凄い。
サーバー側にViewの統一的なモデルを用意した。
これにクライアント側にあるVMを1:1でくっ付けるようにすることで、
クライアント側のVMは必要最低限なVへのコンバートだけで済むようになった。
VとVMは各プラットフォームに合わせて設計し、VMはMをAPIとして呼ぶようになった。
サーバーを通したマルチプラットフォーム上のソフトの開発では、
統一的なViewの登場により、MVVMが2層から3層になった。
V ← VM ← M(統合的ViewのModel+他のModel)
おわりに
これはアンチパターン。
このような情報はささっと捨てましょう。
鵜呑みにするとひどい目に合う。