遷移について
開発っていうか、今日ふと思ったことを。
VBとかでプログラムを書いてきたひとって、処理の流れの主軸が画面になっている気がする。確かに最終的にユーザさんが認識するのは画面であり、画面の移り変わりで処理を行なっていると思えてしまうのでしょうが、実際のところどうなのかと？
私が思うに本質的には画面が主ではなく、なんらかの業務を処理させるのに流れの主となるのはいわゆるアクションと呼ばれるものではないかと。画面はあくまでモデルの内容を投影したものでしかなく、「このボタンを押したら〜させたい」という要求を実行する部分が流れの主であると。こうして書いてみると当たり前なことだなと認識。文章が下手で意味わかりづらいけどね。(汗)
でも、この当たり前のことが分かっていない人が多そうなヨカーン。その画面で何がしたいのかの本質を考えず、目に見えるものをそのまま実装してしまう人がおおいのかも。
いま仕事で触っているソースコードについての感想なんだけどね(汗
適当に流れを箇条書きしてみるテスト。
- 画面のボタン等が押される
- ボタン等に関連付けられたアクションが起動
- アクションがモデルに対してメッセージを送信
- モデル内の業務ロジックが実行され、モデルの内部状態が変化
- モデルの内部状態に対応して画面が変化(この画面の変化には他画面の表示も含まれる)
アクション = Controller の役割になっているかな。画面はもちろん View です。
さて、上記の流れでは画面が切り替わることで他の処理へ遷移しているのか？否、他の処理の端点となるアクションが実行されることで処理の遷移が発生していると考えられる。まちがっても画面が切り替わることが契機なわけではないと思う。(切り替わらないこともあるわけだし。画面の遷移は処理結果の一つでしかない。)
でだ、こういうのってMVCをよく理解(いや、べつに常にMVCをしなければいけないって意味ではないんだけどね)していれば発生しないんだろうなぁと。というわけで、やっぱりMVCをきっちりサポートしたフレームワーク(http://d.hatena.ne.jp/NetPenguin/20040507#p3)をつくろうと！
ちなみに私の脳内ではこのフレームワークは M と V にほぼ依存性がないので、同じ M で V を差し替えられるかもと。うまくやれば V がWebアプリだったり、リッチクライアントだったりというのも可能かも。
