WPFについて
※今回はAIとは全く関係ありません。
WPFが良いとか早く移行すべしみたいな話をよく目にするので、ちょっと調べてみた。
(というか元から存在となんとなくの概要は知っていたが)
ということで、まずは軽くまとめてみようか。
利点
欠点
- 使用できるコントロールの種類が少ない
- コントロールの形状自由度が上がっても、種類が少なくては...
- 学習コストが高い
- 参考になる資料が少ない
- 要素技術の抽象度が比較的高く、実際の操作と結びつきづらい
- プロパティの説明が画面上に出ない(ことがある?)
- Windowsフォームアプリケーションでの知識があまり生かせない。
とまぁこんな感じで。
俯瞰してみると、利点が多い分だけ欠点が多い。
しかもその欠点が、WindowsフォームからWPFへの移行を直接妨げるような内容である点が致命的。
移行を促しているのに、移行しづらいとはこれ如何に。
WPFへの移行が全然進まないと言われているのも頷ける。
個人的には、WPFの利点を見ると結構使ってみたいなとは思う。
ということで少し触ってみたんだけれども
Windowsフォームアプリケーションとは作り方がかなり異なっていて
正直説明なしで適当に触るだけではよく分からなかった、というのが小学生並みの感想。
なので、ネットで参考になるサイト等を適当にぶらついてコピペとかしてたらなんとなく書けた。
書けたけれども、DataContextって結局なんだ?ってなる。
データバインドを行うために必要なWindowのプロパティなんだろうってのはなんとなく察しは付くけれど、より詳しく説明していたりするサイトってのが非常に少ない。
それこそ、「適当にインスタンスを突っ込むんやで」くらいのノリでしかない。
で、実際にリストとか適当に突っ込んでみると期待した動作をしない。
参考にしたサイトの記事作成者がそれをみてほくそ笑んでいるのが目に浮かぶ。
因みに、リストをそのまま突っ込むと都合が悪いので、リストをプロパティとして持っているクラスを作って、そのインスタンスを投げてあげると、上手く動いてComboBoxにリストを表示できたりする。
さてここで疑問だが、異なるクラスをデータソースとするDataGridViewが複数あるときはどうすれば良いのだろうか。
DataContextの受け口は(多分)一つしかないのだから、まさかそれぞれ別に投げることはできまい。
これは推測だが、それらのクラスを全て内包する一つのまとまりクラスを作成しなければいけないんだろう。
Windowsフォームでは、それぞれが別々にバインディングソースを持っていて、バインドさせたいクラスをまとめなくても利用できたのでなんだか違和感があるが。
しかし、よく考えてみると、このようにUIで使用する値をまとめてしまうこの構造こそが、MVVMにおけるViewModelなのだと考えると、確かにModelとViewの癒着は少ない気はする。
MVVMという考え方自体なんとなくの概念としてしか知らないので、これがViewModelの正しい姿なのかすら分からないのだがね。
結局DataContextとは、あるインスタンスのプロパティをUIの表示に用いるための受け口、若しくはUIとやりとりするためのパイプなんだろうな、と素人的には思う。
正直、Windowsフォームアプリケーションの方に慣れすぎてしまって、今のところWPFを上手く使いこなせる気が全くしない。
気が向いたら勉強してみようとは思うけど、優先度はかなり低いかな。