MVPVMパターン(その弐) - 周回遅れのブルース

ここ最近、MVVM をプロジェクトにスムーズに導入できない問題に関してずっと考えてました。MVVM をうまく摘要できないケースを大別すると、以下の三つに分類できるのではないでしょうか？

そもそもパターンが何か判らない。
適切なインフラを使用しない、もしくは使い方が判らないため利用できない。
旧資産を利用しているため、パターンをうまく適用できない。

1．は VB6 からの.NET への移行組で、イベントドリブンに依存する開発にずっと終始してたケース。基本的なOOPもよく判らず、パターンの学習もしたことがない、したけどよく判らないという方々。これは、頑張って学習するしかないでしょう。

2．は MVVM をプロジェクトに導入するものの、適切なツールを用いないため作業時間が増えてしまう。また MVVM Light Toolkit や Livet 等のインフラを導入したものの、使い方が判らないため開発よりも習得に時間が費やされ、MVVM そのものに対し嫌悪感を抱いてしまうケース。確かに情報が少ない時代は厳しかったかも知れませんが、今は一年前に比べて有用な情報が増えてます。Livet も近々正式版がリリースされてドキュメントも整備される予定なので期待できます。

3．Forms から WPF に移行するにあたり、従来の機能を実現するため ActiveX を使わざるを得ない、また時間的・機能的問題で MultiRow・ActiveReports などの Forms コンポーネントを使わざるを得ない、いわゆる相互運用機能を使った画面。
1・2　はともかく、このケースに MVVM パターンをそのまま適用するには無理があるように感じました。そもそもアーキテクチャの全く違うものが View に存在してるのは問題です。ActiveX の中には高機能を謳って、ビジネスロジックを含んでいるものもあるため、さらに話が厄介になります。

そこで XAML クラスタに嫌われてる、かの MVPVM パターンの登場です。

View〜ViewModel 間は従来のとおり、ただし View の中にある相互運用機能と ViewModel を結ぶラインに Presenter のクッションを設け、VM〜M間のラインは従来どおりとします。Presenter は単なる Adapter だけじゃなく、相互運用の機能によっては Model とも結びつくケースもあるかも知れません。これを図にするとこうなるんではないかと・・・

ちなみになんでこんなこと考えてるのかといえば、いまのプロジェクトでも ActiveX とか Forms 専用コンポーネント、View にペタペタ貼り付けてるからです。ActiveX の扱いには、苦労させられてます・・・(ＴＴ)