MVVMについて語ろう

1 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 11:03:33.21 .net] WPF/Silverlight/WinRT開発の必須技術、MVVMについて語ろうではないか！ 3 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 12:06:49.93 .net] 語れるほどニーズあんのか？ 4 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 12:30:27.30 .net] MVCよりはまし。 でも、MVCすら理解できないのが大半だからなー 5 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 12:40:59.59 .net] MVPとMVC混同してる人けっこういるよね 6 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 12:50:21.81 .net] UIパターン知らんでMVVM知ろうとしても無理ゲー 7 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 13:04:32.71 .net] >>5 実装上の違いだけで本質的には同じもの そこにこだわるってことは、たぶん本質が分かってないんだろうな 8 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 14:22:00.43 .net] 語ることあるのか知らんが期待しとく 9 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 14:34:22.26 .net] 要するにXAMLで開発してれば自動的にMVVMなんでしょ？ 開発環境を作ってるのでも無ければ、あんまり純粋主義主義者になる意味は無いと思う。 10 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 14:36:36.66 .net] このスレッドは天才チンパンジー「アイちゃん」が 言語訓練のために立てたものです。 アイと研究員とのやり取りに利用するスレッドなので、 関係者以外は書きこまないで下さい。 　　　　　　　　　　　　　　　　　　京都大学霊長類研究所 11 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 15:10:32.26 .net] MVVMツールがVSに標準装備されてないことか推測するに、MVVMがXAMLUIに必須でないことが判る 12 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 15:41:03.54 .net] >>9　自動的にMVVMではない。 >>11　必須ではないが有用。 13 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 16:24:21.12 .net] デザインパターンと同じで、フレームワークの名称じゃないからね 自分でフルスクラッチしてもいいんじゃよ？　別にむずかしくないし でも「mstest？　なにそれおいしいの？」って子は 本来のメリットの半分もえられないからこれまで通りにかけばいいんじゃないの 14 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 19:44:35.03 .net] MVVMで実際のDBに繋いでCRUDのサンプルってないね。 DBのあたりはEntity Frameworkでいいの？ 15 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 19:53:11.38 .net] つか語呂悪い。なんで最後だけ二文字なんだよ。 16 名前：デフォルトの名無しさん [2012/06/06(水) 19:56:31.71 .net] >14 プレゼンテーション層以外はすべてModelなのでどうでもいい話 >15 回文 17 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 19:59:28.53 .net] >>15 じゃあ何て略したらいいんだよｗ 18 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 20:01:18.77 .net] Mのぶぶんは別になんでもいいお。 そもそもMの部分はVMとのセパレーションさえできていればいわゆるModel的なものですらなくていいと思う。 なんというかViewに関連しないものでありさえするなら、ステートを持つ実体的なものでもサービスとのやり取りをするProxi的なものでもなんでも。 実際のアプリではVMとMが一体化してるようなものもあると思われ。 19 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 20:13:26.93 .net] アプリケーションや実装固有の話だからといって、MVVMにおけるMやMVCにおけるMのパターンを語る気が無いなら 「V-VM-VとVM以外パターン」とか「V-C-VとC以外パターン」とか言っておくべきだな。 20 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 20:42:38.20 .net] Mはドメインロジックなのでモデルといって問題ない 21 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 20:47:41.09 .net] つうか、むしろ話としては、VVMな部分の話よりも、MVVMにおけるMの話の方が語ることは多いと思うが。 VMとして責務を分離する話に、スレを立てるほどの広がりがあるのかなあ？ 22 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 20:48:35.99 .net] ドメインロジックという言葉が何に対してでも都合良く使われる問題。 23 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 20:48:37.04 .net] 実装の話とか？ 24 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 20:51:59.61 .net] >>22 それはすげー思うｗ 25 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 20:54:32.74 .net] Mについてはそれなりに構築できるけど、 そこにVを被せるときに毎回苦労するんだなー 26 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 20:58:39.14 .net] 対象領域の課題を解決するためのモデルの「対象領域」の部分を拡大解釈しすぎなんだよ。 MVVMの文脈で、プレゼンテーションパターン以外の個別のアーキテクチャやパターンとして語るべき物までひっくるめてドメインモデルと言ったり、 ひいては状態を持っているるからドメインモデルです(｀・ω・´)ｷﾘｯ、みたいな事を言っていても、世間一般の同意は得られないと思うけどな。 27 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 22:10:29.54 .net] いやいや、MVVMパターンの目的はXAMLアーキテクチャ特有のプレゼンテーションロジックの解決がメインであって、モデルの問題は二の次以下なんだがな 28 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 23:41:43.34 .net] だからMについては一切語らない、っていうのは別に良いんだけど、それでそんなに語る事がある？、っていう。 まあ、VMとMの接続パターンについてはまったく語らないわけにはいかないだろうけど。 DBの話が知りたいって言う話が出てくるのも、DB実装固有の話がどうのというのではなくて、VMからサービス層とかへの参照を誰が生成してどう設定するのとか、 サービスロケータ的な部分をどうすべきかを知りたいって事だと思っているけど。 29 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 00:03:55.68 .net] それはアプリケーション（Model）の役目だろうよ V＆VMはむしろ生成される側だと思われ 30 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 00:13:47.89 .net] 簡単に言えば V　見た目 M　本処理 VM　接着剤 だろ MVCと同じようにUI層とその他を分けるときどうするかっていうのをパターンにしてるわけで UI以外の処理、例えばデータの読み書きがどうこうなんてのはMVVMには関係ない話だな Modelって名前なんだから何々であるべきなんだ！！１なんて話はナンセンス 31 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 00:14:54.65 .net] その「アプリケーション（Model）」っていう言い方も微妙だが…。 生成されたVMがMをどう参照するかは、VM自体の話というよりアプリケーションインフラの話というならそうだけど。 でも、その話すらしないのだとしたら、本当に何の話をするんだ？ 32 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 00:15:55.19 .net] ザックリ分けると ・DBとのやり取りやAsync、Rxなど含めたアプリケーションロジック的な部分。 ・MVVMとしての各画面の作り方の部分 ・Prism的にDIやサービスロケータ含めたクライアントアプリとして構造的な部分 って感じかね。 33 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 00:16:50.09 .net] >>30で良いなら、それがもう結論じゃん。それ以上なにか言うことがあるの？ 34 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 00:23:50.25 .net] >>33 >>30の話だけでナイスなWPFアプリが作れるんだったらいいんじゃないの？ 35 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 00:36:57.38 .net] MVVMの実装に関する話ならいくらでもできるんじゃね 36 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 01:12:27.18 .net] むしろそちらの方を知りたいという人間多いんじゃね？ MVVM的に考えるとコマンドはVMに置くべきか否か コードビハインドとイベントハンドラとVMの関係 コードビハインドはいわゆるプレゼンターか否か バインディングとMVVMは切り離して考えるべきか否か MVVMとしてふさわしいVMの実装は もっと高速にVMを実装する方法はないかとかね 37 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 01:13:45.85 .net] あとMVVMツールの良し悪しや使用方法についてとか 38 名前：デフォルトの名無しさん [2012/06/07(木) 01:19:01.75 .net] ビヘイビアってよく聞くけどVMに入るの？ 39 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 06:11:20.38 .net] >>32みたいな、アプリケーション構造の話をするのはこのスレではあり？、なし？ MVVMフレームワークの実装比較の話は俺も聞きたいな。 40 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 06:16:05.12 .net] 定義論にまた脱線しない限りまあいいんじゃね 41 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 08:14:29.03 .net] >>39 むしろそのためのスレだろ 42 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 09:30:27.00 .net] Mっとういか、VVMじゃない部分の話をしだすと荒れる傾向にあるじゃん。 その境界がどこかの確認。 43 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 09:57:41.92 .net] >>42 新参者だが、荒れるん？ むしろMVVM作る上で重要なファクターだと思うんだが。 44 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 10:11:41.27 .net] Modelって言う言葉が出るだけで、すぐ定義論と決めつけて、プレゼンテーション層以外のどうでもいい話なんです！、な発言が出てくるから。 その一方で、アプリケーション構造部分までModelという言い方をする人も居るので。 45 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 10:16:56.33 .net] 何度も言うが、MVVMで焦点当てて考えにゃならんのはプレゼンテーション層であって、Modelは二の次だと何度いわせりゃいいんだか MVVMがXAMLというDSLに極めて特化したパターンだということを考慮せねばならんよ 46 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 10:28:50.09 .net] 本来VとMだけ分離すればいいのだが、XAMLの場合、バインディングを強く意識した設計になっている。 そこでV〜M間に仲介者を設け、V(XAML)、VM（C#）の二層構造とし、VMにViewの状態とModelのデータを保持させて V〜VM間をバインディングで通信するのがMVVM。 47 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 10:30:41.00 .net] ほらｗ >>45の意見なら、このスレですべきは>>36みたいな話であって、>>32みたいな話は別途 WPF/MVVMおけるアプリケーション構造について語ろう、みたいなスレを立てろって話になるし。 48 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 10:35:21.73 .net] >>45 それは>>32でいう2つめを見てるだけであって、実際のアプリを作るには１も３も必要だろ。 49 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 10:58:40.42 .net] ＞DBとのやり取りやAsync、Rxなど含めたアプリケーションロジック的な部分。 ってMVVMとどう関係あるの？ 洋の内外問わず、これについて論じてるMVVMの記事って見たことないんですがｗ 50 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 11:00:01.66 .net] >>48 VMとM間の通信は考えなければならんが、M内の構造については別のパターンを導入すべきだろ 51 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 11:04:12.67 .net] >>49,50 M内の構造はMVVMとは関係ないよ。 でも実際のアプリを作る上ではどこまでをMとするか、そのMをどういう仕組で作るか、それらとV,VM含めたものを紡ぎ上げるにはどうしたら良いか考えないと出来ないでしょ？ MVVMはあくまでもUIを作る上でのパターンであって、実際のアプリはその他のパターンが組み合わさったもの。 52 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 11:07:44.33 .net] >>51 ああ、ごめん。IDが出ないから流れがわかりにくいなこのスレ >>49は>>47への反論です >>50も俺だけど>>51と全く同意 53 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 11:16:28.31 .net] >>46 そもそもVMはV層でしっかりVとMの分離になってるんじゃないか Mの設計がVMなしにそのまま使える物であればVMの省略もしばしばみられるし 54 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 11:18:42.66 .net] やっぱり、VVM内に閉じた話だけを扱うスレなのか？、MVVMを使用したアプリケーションの構造まで扱うのがOKなスレなのか？、っていう最初に戻るじゃん。 VMとMの繋ぎは考えるなら、サービスロケータあたりの話からがグレーゾーンになってくると思うけど。 55 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 11:26:13.73 .net] 定義論に発展しない限りどうでもいいと言ったら定義論がヒートアップしてたでござる 定義知りたきゃMVVMでぐぐってろ 56 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 11:27:07.00 .net] そもそもMVVMってなに？ 57 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 11:27:49.63 .net] >>56 >>2 58 名前：wikiから抜粋 mailto:sage [2012/06/07(木) 11:33:08.35 .net] Model アプリケーションのドメイン(問題領域)を担う、そのアプリケーションが扱う領域のデータと手続き（ビジネスロジック - ショッピングの合計額や送料を計算するなど）を表現する要素である。 多くのアプリケーションではデータの格納に永続的な記憶の仕組み（データベースなど）が使われていたり、 サーバが別途存在するアプリケーションではサーバ側との通信ロジックなどが含まれている。 MVVMの概念ではMVCの概念と同様に、データの（UI以外の）入出力は取り扱わないので、強いて言うならばそれらはModelの中に隠蔽されると考えられる 一般的にModelはドメインを担当すると言われるがこの言葉だけをもってModelの役割を想像するのは難しい。 たとえばクライアントサーバモデルのアプリケーションのクライアントアプリケーション側は、そのドメインそのものがプレゼンテーションになっている。 アプリケーションをプレゼンテーションとドメインに分けて考えようとした際にはこの事が混乱の一因となっている。 Modelの役割は、後述するViewとViewModelの役割以外の部分と考えるのが妥当である。 59 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 11:34:10.24 .net] MVVMの定義自体は、みんなさほど異なる認識を持っているとは思わんが。 それをわかった上で、アプリケーション固有の話が出てくるのをわかった上でアプリケーション構造の話をするか、しないかについて話てるだけじゃね？ 60 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 11:36:30.09 .net] >>58 それってU氏の記述だろ？ 61 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 11:40:56.25 .net] わかりにくいからMVVMをガンダムでたとえて 62 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 11:47:53.91 .net] >>54 そこまで細分化しても意味ないと思うから、自分はぜんぶ含めていいと思うの(´・ω・｀) 63 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 11:49:55.46 .net] >>61 M=ララァ VM=サイコミュ V=ビット 64 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 11:58:29.11 .net] >>63 なんとなくこれ思い出した d.hatena.ne.jp/hilapon/20120426/1335411488 65 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 12:54:35.30 .net] スレのあり方を議論するだけで終わりそうだｗ 66 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 13:03:38.18 .net] おまえが勝手に思ってるだけだろ 67 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 13:17:43.48 .net] 質問です。 ButtonクリックしてViewModelからWindowクローズしたいんだけど、ViewModel側にはどう書いたらいいのでしょうか？ 68 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 13:21:47.51 .net] ウィンドウを閉じる動作はViewで完結しているものなんじゃないでしょうか 69 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 13:57:19.39 .net] ウィンドウサイズ保存したい 70 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 13:57:28.88 .net] >68 そうなんですか？わかりました...(´･ω･`) 71 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 14:36:34.99 .net] >>69 コードビハインドで実装すればいいよ 72 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 14:36:56.58 .net] >>68 未保存のデータがあるときだけ確認メッセージを表示とか、Viewだけじゃ完結しないだろ。 73 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 16:02:42.75 .net] LivetのMessengerクラス使えば、ViewModelからWindow閉じたり最大化・最小化を操作できる d.hatena.ne.jp/hilapon/20111108/1320728308 74 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 16:10:07.46 .net] よし分かった、俺がこれがコードビハインドだって お手本のプログラムを作って見せてやるよ。 75 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 16:21:57.25 .net] >>73 他のMVVMツールにも同様の機能はありますか？ 76 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 17:01:49.59 .net] >>75 その部分だけパチってくればいいじゃん。 77 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 19:40:33.37 .net] ugaya40さん、MVVMの本書いてよ。 78 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 20:19:01.71 .net] 彼は文書よりもLivetのチュートリアルの優先度をあげるべきだろ。 79 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 20:39:57.25 .net] チュートリアルないと使えないか？ サンプルなら探せばそれなりにあると思うけど 80 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 20:47:05.63 .net] 使える使えないという話ではなく、広くアピールしたいならそういう地味な作業の優先度の方が高いんじゃないの、という話。 81 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 20:47:06.97 .net] ugaya40さんって誰？と思ってこれを読んだけど ugaya40.net/wpf/mvvm-mvc-mvp-pm-eventdriven.html MVPとPresentation Modelの認識がおかしいな まぁ全体として意味は通じるけど… 82 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 20:52:17.02 .net] ところで、これってMVCとどう違うの？ MVCのときとMとVも当然違うと思うんだけど。 83 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 20:52:18.22 .net] u氏の言っていることは、VVMや実装の話についてはほぼ同意だしすごいとも思っているけど。 ただ、そこからMよりの話やもっと大きな構造の話になってくると、言っていることが微妙というか、 言おうとしていることはわかるけど、他の人の同意は得られないだろうな、っと思うことが多いかな。 84 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 21:28:22.45 .net] Livet使ってるけど2chの名無しに返信しないで欲しい、とだけ言っておきたい 85 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 22:11:46.33 .net] Livetネタは荒れるからやめろ。 本人に直接聞け。 86 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 22:23:47.65 .net] >>77 そんなニッチ層向けの本書いても売れないだろ 87 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 22:59:32.63 .net] MVVMってどれがええの？ Livetがオススメ？ 88 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 23:01:51.98 .net] mvvmlight 89 名前：デフォルトの名無しさん mailto:sage [2012/06/08(金) 00:29:17.99 .net] それはプログラミングにどの言語がいいのかと聞くようなもので PrismもLivetもMVVMLightもどれも一長一短だからな 人に聞けばたぶんバラバラに返ってくるだろうから 一度使ってみて使いやすいのを判断したほうが早い 90 名前：デフォルトの名無しさん mailto:sage [2012/06/08(金) 01:33:55.43 .net] >>81 どの辺が認識おかしいの？ 91 名前：デフォルトの名無しさん mailto:sage [2012/06/08(金) 08:13:09.32 .net] >>89 そういうんでは、その一長一短を聞きたいんだろ。 ぜんぶ試すってのはなかなか難しい。 92 名前：デフォルトの名無しさん mailto:sage [2012/06/08(金) 10:23:56.69 .net] >>86 いや、結構売れるかも知れんぞ。 93 名前：デフォルトの名無しさん mailto:sage [2012/06/08(金) 11:41:06.72 .net] VMへのサービス層のDIってどうやるべきものなの？ それ以前に、VMとMを繋ぐ方法として、VMにサービス層をインジェクションする、っていう考え方はあってる？ 94 名前：デフォルトの名無しさん mailto:sage [2012/06/08(金) 11:59:23.74 .net] >>93 時と場合によるんだろうけど、そうするとMでやるべきのがぜんぶVMに来ない？ 95 名前：デフォルトの名無しさん mailto:sage [2012/06/08(金) 12:38:59.57 .net] >>94 自分が想定したのは以下の様なサービスファサードがあったとして。 interface HogeServeiceFacade { IE<Foo> GetFooList(); } HogeServeiceFacadeの実装の中では、外部サービスにアクセスしたり、ドメインモデルによる処理をしたり。 HogeServeiceFacade自体はバッチやWebでも使うものだとして。 ここがファサードになるので、それ以上Mの処理がVMに来ることは無いと思っているんだけど。 っで、このHogeServeiceFacadeとVMを接続する方法にコンテナ/サービスロケータを使う場合に どうするのかとか？、それって考え方としてそもそもあっているの？、っていうのを聞きたかった。 96 名前：デフォルトの名無しさん mailto:sage [2012/06/08(金) 12:44:10.40 .net] >>95 そういうんではありなんじゃない？ そもそもMVVMは大本はViewとMの分離があって、それにさらに薄いVMいれると更にセパレーションで来て良いよねって話だから。 で、ロケータ使う場合色々あるけど既存の使うか自前で作るかじゃない。 薄いやつなら実質ただのKeyValueで出来るだろうし、それで結構まかなえると思われ。Prismとかはその辺も実装されてる。DIがより良くインテグレートされてる。他は知らん。 97 名前：デフォルトの名無しさん mailto:sage [2012/06/08(金) 13:03:47.05 .net] コンバータ(IValueConverterを実装したクラス)はMVVMのどの層に属するものなの？ 98 名前：デフォルトの名無しさん mailto:sage [2012/06/08(金) 13:07:30.90 .net] >>97 View 99 名前：デフォルトの名無しさん mailto:sage [2012/06/08(金) 13:20:41.29 .net] コンバータ自体簡易VMみたいなもんじゃね？ 100 名前：デフォルトの名無しさん mailto:sage [2012/06/08(金) 13:32:59.19 .net] >>97 それを分類することに何か意味があるの？ 101 名前：デフォルトの名無しさん mailto:sage [2012/06/08(金) 13:47:18.95 .net] コンバータ、StringFormat、VMでの詰め替え等が混在していると保守性が悪くな� 102 名前：閧ｻうだ [] [ここ壊れてます] 103 名前：デフォルトの名無しさん mailto:sage [2012/06/08(金) 13:55:44.00 .net] VMでなんでも出来はするるが、責務としてVMでやるのはデータ構造の変換までにして、色だの文字だのの修飾はコンバーターでやるべきだろう。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef