ViewModelをシンプルに書きたい！ - ⑥MVVMを考える編 - MVナントカ -

基本に帰ってMVVMの話です。そんなMVVM得意ってわけではないですが、自分の中の整理の意味も込めてアウトプットしてみます。このシリーズの⑤までの話もこの考えに基づいています。それからMVナントカに関しては、あくまでWinFormsやWPFなどのリッチクライアントを対象としていてWebアプリのそれとは異なってきます。

そもそもMVナントカってViewとModelを分けたいんですよ。

いやもう、本当にこれを実現するためだけですよね。なんで分けたいのかというと、Viewってかなり特殊なのです。そしてModelって複雑なのです。

Viewは魑魅魍魎の住まうGUIライブラリのお相手

View回りはどうあがいても、GUIライブラリ(標準はもちろんサードパーティーも)を使わないと作れません。またそれが大変ですよね。情報収集のためにgoogleに聞き続けるのはもちろん、掲示板で質問して怖い人にググレカス的なこと言われたり。場合によっては不具合があってライブラリ作成の会社に問い合わせ投げたり。アプリの仕様書見て考えるよりは使ってるGUIライブラリの使いこなしがメインになりますね。WPFで作るならもちろんWPFの調査が必須です。

Modelはそれ以外

極論するとこうですね。ちなみに若干引っ張られる部分はあるにせよ、MVCだろうがMVVMだろうがModelは同じような設計になるはずです。当然Modelの設計はMVCとはまた別に色々考えて設計する必要があります。同一アプリ内にあっても関係性の薄いものは疎結合にしておくとか通信レイヤは抽象化しておくとかね。これができないとMVナントカのどれ使っても上手くいきませんよ。

ナントカはViewとModelを協調動作させる

ナントカはViewとModelを協調動作させることが役目ですね。全てを知ってる。でも実装は殆どない。つないだり言葉を変えたりです。言葉を変えたりっていうのはViewからは具体的なGUIをイメージする言葉で話しかけられますが、Modelに話しかけるときは抽象化されたまろやかなインターフェイスを呼んで処理を実行させて、表示用の情報をViewに渡してやるとかですね。ちなみにMVCのコントローラーはイベントを受けるといわれていますが、リッチクライアントでは生のイベントはGUIライブラリに密に依存するのでViewで受けて中継してもらうのがいいと思います。

混ぜるな危険

ViewとModelはそれぞれ、全然違う技術を使って作るものなんですね。混ぜるな危険。繰り返しますが、この二つを分離することがMVナントカの悲願なのです。混ぜると難易度上がるし、コードが歪みます。例えばビジネスロジックに特定のGUIコントロールの癖を回避するための変なロジック入れてみたりとか。
それから使いまわしづらくなる。それは当然の話でView+Modelの条件が完全にマッチする箇所なんて同一アプリ内でもほとんどないですよね。だからコピペして微妙な差分を書き換えるとかいうコードが量産されるのですね。ViewとModelが分かれていたら、View側の類似性、Model側の類似性で共通化、部品化できる部分は増えるわけです。

で、MVVMは・・・

長くなりましたね。次回に続きますw

連載で使っているMarkup拡張のコードはこちらにおいてます。

github.com