WPFアプリ構築の敷居もグッと下がったと思う。このライブラリがMicrosoft標準でないというのが、WPFの悲劇なのでは。
Prismを使ってWindowsのデスクトップアプリを作っているのですが、だいぶ慣れてきた。かずきさんのレポジトリを見て写経すればまずOK。MVVMのやり方と画面遷移のあり方が書いてあるので、その2つがあれば生きていける。Prismはよく出来ているライブラリですわ。
XAMLが好きになってきた
最初はなんだよこのハイパー拡張HTMLはと思いましたが、XAMLに慣れてしまうとWindowsフォームで画面を作るのは無茶苦茶だるくなりました。テキストで全部が表現されているのは正義だ。似たような画面作るのすごい楽。ViewModelのインスタンスはDIしてくれるのも楽なんだよな〜
画面遷移が便利すぎて感動
Region機能を使わないでPrismでアプリを使うことはありえない。今回、こいつがすごく便利でびっくりしている。
HTMLのコーディングと一緒で、MainWindowにヘッダーとフッターだけは共通化して定義。あとは「Contents」みたいな感じにして、そこだけPrismからユーザーコントロールを当て込む。これだけで生きていけるようだ。
かずきさんのレポジトリにあるように、PrismのUnityBootstraperの機能で画面とViewModelが予め全て初期化された状態でアプリが起動してくれるので、画面遷移した時は遷移前の状態が残る。残ったほうが便利なんだよね、間違いないんだよね。
ダイアログを起動してコールバックをするというのは、IntercationRequestなるものを使えばいける。YES/Noも取れるし、画面を起動する時にその都度パラメーターを与えてバインドさせることもできる。任意の型のパラメーターを受け渡すことができる。
ダイアログではなく、Contentsページの切り替えも簡単にできる。当該画面が画面遷移によって表示される時と、当該画面が遷移によって消える時の両方にコールバック関数を定義することができるし、任意の型のパラメーターの受け渡しもいける。
RegionManagerクラスのインスタンスは、任意のViewModelのプロパティにDIすることができる。親画面のメニューをクリックして画面遷移、データグリッドをEnterひっぱたいて画面遷移の2パターン等が多いと思いますが、この２つは別のViewModelですよね。でも、PrismがDIしてくれることで、同じインスタンスがSingletonで引き回せるため、どのVMからも画面操作が可能。これは便利。
5年ぐらい前のWindowsフォームで作ったシステムのように、PanelにAddControl/RemoveControlしていた原始的なやり方に比べると、近代的で大変すばらしい。
コードビハインドからのVM
DataContextプロパティをDIされたViewModelにキャストすれば、どうとでもなる。
ただ、ほとんど使わない。Commandプロパティにバインドできるし、KeyイベントもInputBindingsを使えばどうとでもバインドできる。コードビハインドを余儀なくされたのは、任意の画面のコンポーネントにフォーカスを移す時。それ以外は殆どCommandをバインドすればいけるんじゃないかな。ViewModelを継承すると、更に便利。イベントは一緒だけど処理が違う(コマンドの中身が違う)という差分だけ実装すれば、生きていける。
DataGridの編集可能カラムで発生するキーイベントについては、コードビハインドで書いた。ViewModelとは関係なく任意のロジックを持っているクラスに処理を投げたかったので。
引き続き頑張ります
まだ5画面ぐらいしか作ってない。本番では60画面ぐらいになる予定なので、重くないかどうかはとても気になっている。でも、Prism+WPFの組み合わせは最高に便利だし、生産性も高い。引き続き頑張るぞい。
