- - PR -
イベントの伝播
| 投稿者 | 投稿内容 | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2008-05-16 20:27
子 View がトップレベルの Doc を直接参照するのではなく、親 View が保持する「子 View 用の Doc」を参照する方式を採用する場合、親がイベントで受け取ったトップレベル Doc の変更を、親 View が保持する子 View 用の Doc に反映して、それをイベントで子 View に通知する、てな具合すればよいのではないかと。 そういう話ではなくて、ですか？ | ||||||||||||||||||||||||
|
投稿日時: 2008-05-16 20:27
indigo-xさんの説明をどう受け取るかとか
自分の経験してきた事例の違いとかが出ますねぇ。
ええ。気になるほどではないですね。 「イベントを使う方法」と「参照と関数呼び出し」の二つが ほぼ同等の機能であって、 どっちかを選ばなければならないので より無駄の無いほうを選んだだけです。
MVCをいちいち実装するのは結構めんどくさいのですよね。 それに、Cを内蔵するVがあるので、 GUIによってはVとCがなかなか分けられない。ListViewとか。 前の投稿で述べたように作るとM/VC(～Doc/View)になるので 普通はその程度で終わりにしてます。 DBが噛んでない限りはその程度の規模のものしか作りません。 ユーザーがいっぺんに把握できるデータの量というのはそれほど多くないので、 MVCをがっちり組むコストに見合わないことが多いのですよね。 まぁその人のEnvironmentに依る話ですね 私はそういったEnvironmentにいるだけです。 ところで。
ん～？ この辺を読む限り話が通じてない感じがします。
こちらもほぼ同様で。 そんなに「更新」の管理が大変でしょうか？ 特殊なインタフェースなのでしょうか？ MVCならタイミングはきちんとCが解決できなければならないわけで。 更新のタイミングもCが管理するべきで。 Changed、Selectedで何かしなければいけないなら、 VがCに指示を仰げばいいだけなので、 そんな複雑にはならないはずですが。 WndProcとかの話もさっぱり見えませんし。 もしかしてぜんぜん違う次元をしてるのかしら。 | ||||||||||||||||||||||||
|
投稿日時: 2008-05-16 20:35
なので、「お行儀よく MVC で」とは書かず、Doc/View をメインに書いてみました。 がっちりとした MVC を組まなくても、モデルがしっかり分離されていれば、それほど酷いことにはならないです。
僕の場合は TreeView で悩みますね。 作ってるブツの規模や複雑度なんかによっては、元ネタを TreeNode.Tag に放り込んでオシマイにすることもあります。 ListView の場合はハナから元ネタをコレクション等々で持ってることが多いので、逆に悩みません。 （そもそも元ネタが配列や単純なコレクションで表しやすい、てのもありますが） | ||||||||||||||||||||||||
|
投稿日時: 2008-05-16 21:17
なるほど！ それはいいデザインですね。
親 View が子 View に通知するっていうところが同じなので あんまり変わらないと思うんですよね。 未記入さんの発言で気づきましたが Selection も Model のほうにカプセル化すればいいと思いました。 (親 View で子 View 用の Doc を作るより) | ||||||||||||||||||||||||
|
投稿日時: 2008-05-16 22:31
難しくて人の回答はちゃんと読んでいませんが、とりあえず自分の書きたいことだけ書いておきます。 まず、簡単のため「逆方向」は考えないとします。 そして、(1), (2), (3) のどれかと言えば、私は(1)を選びます。これは Form をコントローラーとして働かせたいからです。Form が UserControlA からのイベントを受けて、それを解釈して、コントローラーの仕事として、UserControl1,2,3 のメソッドを呼び出します。 Form がコントローラーだけではなく、モデルとしての立場も併せ持つ場合は (2) でも良いと思います。この場合は Form が UserControlA をモデルとして集約している、と考えられます。ただし、こうなると構造が複雑になってきます。 (3) は意味が良く分かりませんでしたが、UserControlA と UserControl1,2,3 の関係が密すぎてまずいような気がします。 つぎに「逆方向」も考えた場合ですが、UserControlA と UserControl1,2,3 の立場が入れ替わったものが、並列して存在するというような作りにするほうが良いと思います。単純に順方向と逆方向のものが独立して重なって存在しているような感じです。このためにも仕組みは (1) にしておくと、単純さが保たれると思います。(2) にするとイベントだらけになって破綻しやすくなりそうに思います。 | ||||||||||||||||||||||||
|
投稿日時: 2008-05-17 07:08
沢山の回答ありがとうございます。
（なかなか文章だけでは伝わりにくくて。。。） その中でModel/Viewにならない理由の一つに 指摘の以下があります
この様なタイプも何回か作成していますが、TreeView自体がモデルにならなけば ならない事も多いいですね。 ノード操作(追加/削除/移動）が出来てかつTree構造自体をシリアル化する場合など。。。。 今作成しているのはノード操作ができてTreeNode.TagにはKeyと更新日時とその他 入れています。でノード操作の場合は即DBを更新しています。 あと、以下も気になりますが。。。 ・ModelがViewの更新順を知っていていいのかどうか？ ・ModelがViewの更新順を知るべきなのか？ ・FormであればViewの更新順は知ってて問題ないと思いますが （Form=Modelにすれば参照も少なくなる？） ・Eventを使う場合はEventの通知順は誰が決める？誰が参加する順番を決める [ メッセージ編集済み 編集者: indigo-x 編集日時 2008-05-17 07:30 ] | ||||||||||||||||||||||||
|
投稿日時: 2008-05-17 11:14
> ・ModelがViewの更新順を知っていていいのかどうか？ よくないと思います。 > ・ModelがViewの更新順を知るべきなのか？ 知るべきでないと思います。 > ・FormであればViewの更新順は知ってて問題ないと思いますが > （Form=Modelにすれば参照も少なくなる？） Form がコントローラーとして動くのならば、知っててもそれ自体は問題ないと思います。ただ、そもそも View の更新順を気にしないといけないのはなぜなのか、という疑問もあります。 > ・Eventを使う場合はEventの通知順は誰が決める？誰が参加する順番を決める イベントを使う場合に、順序を気にしないというのは、イベントの使い方が通知以上のことをしているのではないでしょうか。私は、イベントを使うときは、順序を気にしないようにしています。 もっとも、開発の当初から一発ではうまくいかず、開発時(設計時)やデバッグ時に順序を意識したりしますが、リファクタリングの段階で、順序を気にしないですむようにします。イベントの順序に依存したコードが残っているのは、私としてはそれはバグだと考えています。 ＃以下、追記。 上記の中で、「イベントを使う場合に、順序を気にしないというのは」という箇所は、「イベントを使う場合に、順序を気にしないといけないというのは」でした。 [ メッセージ編集済み 編集者: unibon 編集日時 2008-05-17 11:32 ] | ||||||||||||||||||||||||
|
投稿日時: 2008-05-17 11:24
「ならなければならない」ことはないと思います。 「その方が楽だから」それを選択することがあるだけなんじゃないかと。
Doc に（も）その機能を実装すればおｋです。 TreeView で表示する必要があるということは、Doc（あるいは Doc の主要なメンバ）が階層構造をもったデータであるはずです。 ひょっとして、Doc が「たった１個のクラスインスタンスで構成されなければならない」という思い込みでもあるんでしょうか？
知らずに済むのがベストだと思います。
どうして順番が重要なのか分かりません。 | ||||||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。