またしてもWindowsアプリでの画面遷移フレームワークについて フォーム間での変数の受け渡しの基礎についてもチョット
今までも何回かC++ & .NETでの画面遷移について書いていますが。
自分が使っている仕組みを公開してみたり(・∀・)
http://usaxusa.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=27366
Full FrameworkとCompact Framework双方のサンプル込み。*1
公開にあたっては、少し整理して他のライブラリへの依存を削除(その代わり処理をちょっと単純化しているところあり)。
また、今回の機能追加として、制御の対象をContorl以外にもできるように、Contorlに依存している部分をControlViewProviderとして分離。
まあ、手を入れてからあまり動かしていないので、バグがあったら許してミソ(´д｀;)
っで、なんで公開してみたか(・ω・)
よく、掲示板とかで、フォーム間の変数の受け渡しをどうするかみたいな質問があったりしますが。
そこで、「フォームにプロパティを追加しなさい」みたいな解答があったりしますが、それは本質的な回答ではないと思うのですよ(・ω・)
まず、考えるべきなのは、そのデータが本来どこに属するものなのかなのではないかと。
画面間の通知に使用するパラメータがあったとして、その画面間が親子関係にあるものであれば、プロパティという解答でも良いと思いますが。
でも、画面間がピアな関係のものである場合、直接他画面とやりとりすると、画面間の依存関係がおかしくなっちゃいますよね〜、っと。
ピアな関係の場合には、Observer的なものを用意して、通知はそこを経由するようにして、画面間の依存関係は無くすようにすべきだと思います(｀・ω・´)
また、そのデータが画面に属するものではなくて、あるコンテキスト間存在するようなものの場合。
そのデータは画面の外部に保存して、各画面からはそこを参照する形にするかと思いますが。
ただし、その時に気になるのがそのデータのライフサイクル。
グローバル的な所においてしまうと、使われなくなったデータの参照が残ったままになってしまいますし(´・ω・`)
明示的なクリアをするにしても、そういうのってタイミングが面倒だったりします(´д｀;)
なので、この場合には、ある対話コンテキストの間だけデータが存在してくれるような、データのライフサイクルを管理してくれる仕組みを用意することが正解だと思います(｀・ω・´)
あと、画面遷移型のアプリケーションを作成する場合、Form単位で切り替える方式を採用するとどうしてもちらつきが気になりますよね(´・ω・`)。*2
そういう時は、枠としての画面は1つだけ用意して、その中で表示項目を切り替えた方が綺麗に見えます(｀・ω・´)
っで、上記の様な課題にたいして、例えばこんな風な仕組みを用意すれば課題を解決できますよという意味で、ソースを公開してみました(・ω・)
ちなみに、画面遷移の定義を外部ファイル化より汎用的じゃね(・ω・)？、的な事を考えがちですが。
画面間のフローっていうのはコンテキストに依存するものなので、そこまでやるのは無駄というのが自分の意見デス。*3
っというか、このライブラリも色々あった機能を削って今の形にしていたり(・ω・)
