東方算程譚

Oriental Code Talk ── επιστημηが与太をこく、弾幕とは無縁のシロモノ。

目次

Blog 利用状況

ニュース

著作とお薦めの品々は

著作とお薦めの品々は
東方熱帯林へ。

あわせて読みたい

わんくま

  1. 東京勉強会#2
    C++/CLI カクテル・レシピ
  2. 東京勉強会#3
    template vs. generics
  3. 大阪勉強会#6
    C++むかしばなし
  4. 東京勉強会#7
    C++むかしばなし
  5. 東京勉強会#8
    STL/CLRによるGeneric Programming
  6. TechEd 2007 @YOKOHAMA
    C++・C++/CLI・C# 適材適所
  7. 東京勉強会#14
    Making of BOF
  8. 東京勉強会#15
    状態遷移
  9. 名古屋勉強会#2
    WinUnit - お気楽お手軽UnitTest

CodeZine

  1. Cで実現する「ぷちオブジェクト指向」
  2. CUnitによるテスト駆動開発
  3. SQLiteで組み込みDB体験(2007年版)
  4. C++/CLIによるCライブラリの.NET化
  5. C# 1.1からC# 3.0まで~言語仕様の進化
  6. BoostでC++0xのライブラリ「TR1」を先取りしよう (1)
  7. BoostでC++0xのライブラリ「TR1」を先取りしよう (2)
  8. BoostでC++0xのライブラリ「TR1」を先取りしよう (3)
  9. BoostでC++0xのライブラリ「TR1」を先取りしよう (4)
  10. BoostでC++0xのライブラリ「TR1」を先取りしよう (5)
  11. C/C++に対応した、もうひとつのUnitTestFramework ─ WinUnit
  12. SQLiteで"おこづかいちょう"
  13. STL/CLRツアーガイド
  14. マージ・ソート : 巨大データのソート法
  15. ヒープソートのアルゴリズム
  16. C++0xの新機能「ラムダ式」を次期Visual Studioでいち早く試す
  17. .NETでマンデルブロ集合を描く
  18. .NETでマンデルブロ集合を描く(後日談)
  19. C++/CLI : とある文字列の相互変換(コンバージョン)
  20. インテルTBBによる選択ソートの高速化
  21. インテルTBB3.0 によるパイプライン処理
  22. Visual C++ 2010に追加されたSTLアルゴリズム
  23. Visual C++ 2010に追加されたSTLコンテナ「forward_list」
  24. shared_ptrによるObserverパターンの実装
  25. .NETでマンデルブロ集合を描く(番外編) ── OpenCLで超並列コンピューティング
  26. StateパターンでCSVを読む
  27. 状態遷移表からStateパターンを自動生成する
  28. 「ソートも、サーチも、あるんだよ」~標準C++ライブラリにみるアルゴリズムの面白さ
  29. インテルTBBの同期メカニズム
  30. なぜsetを使っちゃいけないの?
  31. WPFアプリケーションで腕試し ~C++でもWPFアプリを
  32. C++11 : スレッド・ライブラリひとめぐり
  33. Google製のC++ Unit Test Framework「Google Test」を使ってみる
  34. メールでデータベースを更新するココロミ
  35. Visitorパターンで遊んでみたよ
  36. Collection 2題:「WPFにバインドできる辞書」と「重複を許す検索set」
  37. Visual C++ 2012:stateless-lambdaとSQLiteのぷち拡張
  38. 「Visual C++ Compiler November 2012 CTP」で追加された6つの新機能

@IT

  1. Vista時代のVisual C++の流儀(前編)Vista到来。既存C/C++資産の.NET化を始めよう!
  2. Vista時代のVisual C++の流儀(中編)MFCから.NETへの実践的移行計画
  3. Vista時代のVisual C++の流儀(後編) STL/CLRによるDocument/Viewアーキテクチャ
  4. C++開発者のための単体テスト入門 第1回 C++開発者の皆さん。テスト、ちゃんとしていますか?
  5. C++開発者のための単体テスト入門 第2回 C++アプリケーションの効率的なテスト手法(CppUnit編)
  6. C++開発者のための単体テスト入門 第3回 C++アプリケーションの効率的なテスト手法(NUnit編)

AWARDS


Microsoft MVP
for Visual Developer - Visual C++


Wankuma MVP
for いぢわる C++


Nyantora MVP
for こくまろ中国茶

Xbox

Links

記事カテゴリ

書庫

日記カテゴリ

ModelとViewは分離し難し

ちょいとした内製アプリを頼まれてて、C#でこりこり書いてるですよ。

扱うデータ自体がTree構造なのでファイルとしての表現は無難にXML、
見てくれはやっぱり無難なTreeViewと。
TreeViewは親子関係を持ったTreeNodeのコンテナとなってます。
XMLのelementときっちり対応がとれますです。

んで、XMLelementの属性の類をclassなりstructなりにまとめ、
TreeNode.Tag 使ってぶら下げ、elementの親子関係はTreeNodeに任せます。

...なんてことやってるとどうにも居心地が悪いんですわ。
つまりね、TreeViewあるいはTreeNodeがViewであると同時に
データとその繋がりを表現したModelそのものになっちまうですよ。
TreeView/TreeNodeそれぞれに対応したModelが用意されていて、
Modelの操作と連動してTreeViewの見え方が変化してくれるなら、
Model/Viewアーキテクチャに則った設計なり実装ができるだろうし、
ModelとXML間のマーシャル・ルールさえ用意してあげれば
XMLをModelに食わせただけでViewができあがるんちゃうかなー
とか妄想するです。

なんてんだろ、きょうびのRADというかIDEというか、
かなりView側に傾いてるように感じます。
本来Model側にあるはずの多くのものがFormの
メンバになってしまうよな。
僕は畑が違うんでよくわかんないんだけど、データベース絡み
ってそれがかなり顕著じゃないのかしら。
データソースだのデータセットだのはModelに置かれるはずのものですよねぇ。

投稿日時 : 2008年1月30日 23:29

コメントを追加

# re: ModelとViewは分離し難し 2008/01/31 0:00 渋木宏明(ひどり)

TreeNode.Tag はもちろん使いますが、それとは別に Model の方にデータをツリー構造で持ってます>じぶん

TreeNode.Tag はあくまで、TreeView が操作された時に TreeNode とした元データを取ってくるためとか、View の便宜のためだけに使ってます。

TreeView がデータ構造を抱え込んでしまうと、アプリが大型化した時なんかにやっぱり困る場合があるんですよね。

簡単なツール程度だったら TreeView に持たせちゃうときもあったりしますが (^^;

# re: ModelとViewは分離し難し 2008/01/31 0:11 中博俊

ただ結局1対1になってしまいがちなのですよね。
MVCフレームワークといわれるものが嫌いなのもそういうところにありやす。

# re: ModelとViewは分離し難し 2008/01/31 0:13 れい

私も気持ち悪いと思ってます。

> TreeNode.Tag はもちろん使いますが、それとは別に Model の方にデータをツリー構造で持ってます>じぶん

大きいものだと私もそうしてますが、
それだと大きいが故にTreeNode-DataTree間に齟齬が起きそうで怖いです。
ITreeNodeみたいにインタフェースにするとか
TreeNodeAdapterみたいなMV変換するクラスを作ってなんとかしたいといつも思ってます。
ある程度大きいときはつくるんですけどね。

# re: ModelとViewは分離し難し 2008/01/31 0:24 επιστημη

そーなのよ。Model側にTreeをこしらえると、Viewとの同期がめんどくせーです。
Model側でのNodeの組み換えがそのまんまView側に反映されるカラクリがあればほんまに便利なんだけど。

# Treeに限らずTableでもMapでも

# re: ModelとViewは分離し難し 2008/01/31 9:13 R・田中一郎

渋木さんと同じです。

僕の場合は、皆さんと違って習熟度が足りないので、正攻法を意識するように気をつけているということもあるのですが。

# re: ModelとViewは分離し難し 2008/01/31 10:24 シャノン

…何ゆーてるか理解できんorz
MVCとかやったことないのバレバレです。

# re: ModelとViewは分離し難し 2008/01/31 10:24 ひろえむ

私も渋木さんと同じかなぁ(^^;

えぴさんのおっしゃることもなんとなく理解できるのですが、やはりViewとModelは切り離して何かしらのコンテナを利用するなり作成するなりして、そのコンテナを渡したら反映するような仕組み(メソッド?)を作りたくなりますね(^^;

なので、Tagにはせいぜいそのコンテナのインデックスのようなものをぶらさげる感じでしょうか。

って、やっぱり渋木さんのそのままやな(^^;;;

# re: ModelとViewは分離し難し 2008/01/31 11:32 επιστημη

ですよねー...

この例ではたまたま(?)View(TreeView/TreeNode)の構造
とXMLが持つロジカルな構造(Tree)とが一致しているから、
Viewの構造をそのまんまModelの実現に使おうとするが
ゆえにModelとViewが癒着してんのね。

目下こしらえてるアプリがさほどに大きなものでないんで
Model/Viewを分離するのは"労多くして利少なし"と判断
したわけなんですけども。

# re: ModelとViewは分離し難し 2008/01/31 11:48 ひろえむ

>目下こしらえてるアプリがさほどに大きなものでないんで
>Model/Viewを分離するのは"労多くして利少なし"と判断
したわけなんですけども。

私も昔はそう思っていたんですが、結局そうすると複雑さから逃れられなくなるんですよね(^^;

独立性の高さの目的って複雑さを避ける意味合いもあるので、デバッグの速さやメンテナンス性の高さからちょっと手間がかかっても分離するように心がけています(^^;

# re: ModelとViewは分離し難し 2008/01/31 12:18 渋木宏明(ひどり)

TreeView/ListView はデータバインドできないですからねぇ。

これは何度も恨めしく思ったことがあります。

けど、TreeView に関しては実際結構難しいですよね。

WPF ではどうなってるんだろう???

# re: ModelとViewは分離し難し 2008/01/31 12:35 επιστημη

うん、attributeの扱いさえなんとかすれば
TreeNodeとXML-elementとのバインドはどってことなさげ
なんだが(てかまんまソレをやってんだけども)。
# attributeはPropertyGridにねぢ込んでまつ

# re: ModelとViewは分離し難し 2008/01/31 21:13 Hirotow

私のATOMEditorもそこで悩んでるんですが、
TreeNode.Tag方式からTreeNode派生方式に鞍替えしてます。
ただそうすると、ParentやらNodes(Children)やらの型で悩むわけです。
Parentはnewでキャストして返せばいいけど、Nodesのほうはそうもいかないし。

タイトル
名前
URL
コメント