AvalonからMVVM、そしてRxへ: GUIプログラミングの哲学の歴史
MSテクノロジ知らんがな、とよしぞうに言われて、そういえばこの辺の話は外ではあまり聞かないな、と思ったので、ちょっと軽く振り返ってみる。 なお、Javaプログラマ向けに一部翻訳してるので、C# の実際とはちょっと違う。 かつて人々は、onclickでリクエストを発行しデータを取ってきて、その間はローディング中としてアイコンを回したりして、帰ってきたらアイコンを戻して取得したデータからtableを組み立てたりしていた。 このシーケンシャルな手続きプログラムは、非同期なGUIという物と大層相性が悪く、すぐにアイコンが回り続けたり途中で何か違う事をすると落ちたりといったバグを埋め込んでしまい、人々は悩んでいた。 GUIプログラムのバグはどこから来るのだろうか？ それはページの動的な所から来る、という観察があった。 静的なhtmlはあまりバグらない。 一旦動く、という事が静的に確認されれば、それ以
AvalonからMVVM、そしてRxへ(その2): GUIプログラミングの哲学の歴史
何故か書きかけで放り投げた前編が妙に反響あったので、一応続きも書いておく。 UIのプログラムというのを、準静的に書く為だけに存在するViewModelという物を導入する事にして、現実の要求と準静的なUIのギャップをだいたい埋める事に成功した人類だが、2つほど問題が残った。 1. UIからViewModelへの通知の粒度のミスマッチ 2. GUIアプリでは非UIの機能を非同期で実装しなくてはいけないが、そことViewModelのマッピングでかつての動的なGUIと似た問題が発生してしまう まず1について。 MVVMにおいては、直接イベントはハンドリングせず、基本的なUIの変化はViewModelのフィールドの変化にマッピングする(かICommandにマップする)。 例えばテキストボックスに値を入れると、対応するViewModelのstring型のメンバ変数(のsetter)に値が入る。 この対
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
