- - PR -
NET のアーキテクチャへの理解について
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2004-11-15 15:10
たつごろー様、ありがとうございます。
日本語化されたページもあるんですね。すべてでないのは残念ですが。 > ポストバックされたらControllerに飛んで > 業務処理をして > 次に表示するview(WebFormとWinForm)はどれかをControllerと業務処理で判断して > xmlに入っている次に表示すべきviewをロードして > レンダリングさせてたはず。 xml が出てくる件は、どういう流れか理解できませんでしたが、 当該ページは Smalltalk 由来の MVC (Model-View-Controller) アーキテクチャ そのものです。 Microsoft のページから、こんな説が語られているのはびっくりしました。 複雑と言えば複雑かとも思いますが、私の経験からは、 ドキュメントビューアーキテクチャも、それなりに複雑でしたから、 当該ページは、私にとっては運良く(?)おもしろいネタとなりそうです。 引用が前後しますが、 > その文章は見つけられなかったんで、前後関係がよくわからないんだけど、 とのことですが、私が取り上げた説明文は、 Application Architecture for .NET: Designing Applications and Services http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/AppArchCh2.asp?frame=true#apparchch2_section3 における Designing Presentation Layers User Interface Component Functionality です。ご参考まで。 今一生懸命、仕事の合間を見つけて(?)読んでいますが、 今のところ "Form1->m_document" にはハズれていないような気がしています... | ||||
|
投稿日時: 2004-11-15 21:59
話題はWebのほうに流れている気もしますが
>ApplicationContext については、Application.Run のヘルプから承知しておりましたが、 >このクラスがどうやらメッセージループのカスタマイズ目的で用いる様子であること >からしますと、確かに MVC 的実装が可能かもしれませんが、クラスの意義を大きく >逸脱してしまう気が致しました。 メッセージループのカスタマイズが目的ってどこかに書いてありましたかね。 http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/cpref/html/frlrfsystemwindowsformsapplicationcontextclasstopic.asp >ApplicationContext クラスを使用すると、メッセージ ループを終了させる条件を再定義できます 「できます」であってApplicationContext派生のできる事のうちの一つですね。 そしてApplicationContextでしかできない事でもあります。 MVCモデリングとは何か、Modelの持つ責務、Controllerのもつ責務、Viewの持つ責務を整理し、責務をまっとうする為の手段のそれぞれとして何が必要か考えられてはいかがでしょうか。 責務のまっとうが目的であって、手段の良し悪しについての議論は責務を満たしてからにしないと机上の空論に入りそうな気がします。 MFCのDocument-Viewについてご存知のようですが、あれは見習うにはいかがなものかとも思いますし。ドキュメント指向では確かに優秀ですが、世の中に存在する多種多様なものにはDocumentでは表現できない、できたとしてもしづらい物が多々ありますから。 _________________ Microsoft Valueable Professional C# 2004 | ||||
|
投稿日時: 2004-11-16 10:17
> メッセージループのカスタマイズが目的ってどこかに書いてありましたかね。 ご指摘頂きましたとおりです。 ヘルプ内に目の付いたキーワードを拾い読みして、解釈した表現でした。 大変失礼致しました。 > MVCモデリングとは何か、Modelの持つ責務、Controllerのもつ責務、Viewの持つ責務を整理し、責務をまっとうする為の手段のそれぞれとして何が必要か考えられてはいかがでしょうか。 > 責務のまっとうが目的であって、手段の良し悪しについての議論は責務を満たしてからにしないと机上の空論に入りそうな気がします。 私の表現がマズいものでした。 何をもって「違和感」があるとしたのか明記せぬままでしたので、 すれ違いのお話になってしまっていると思います。 具体的にどのような設計イメージ、実装イメージで捉えられるものであるか、 例を挙げて考えてみるのも一案かと存じます。 もし宜しければ、どんな様子としてお考えになっていらっしゃるかご説明頂けますでしょうか。 と申すからには私の発想や考えの経緯を記さなければならないところですが、 漠然と感覚的に捉えた部分が多々あるため、じっくり考えてみたいと思います。 ただ一つ、議論させて頂くポイントになるかと感じましたが、 ApplicationContext を用いて MVC スタイルを実現するにあたっては、 Model-View-Controller それぞれの「責務のまっとうが目的であって」、 「手段の良し悪し」はまずは実現した後の議論、というご発言が気にかかります。 手段は悪かったとしても、実現をまず優先して目指すべきというご主旨と捉えて 宜しいでしょうか。 このことも結局は、具体的な設計イメージに基づいた話として進めていかないと、 議論になっていかないかもしれません。 取り急ぎの返信です。投げかけるばかりの発言で申し訳ありません。 > MFCのDocument-Viewについてご存知のようですが、あれは見習うにはいかがなものかとも思いますし。ドキュメント指向では確かに優秀ですが、世の中に存在する多種多様なものにはDocumentでは表現できない、できたとしてもしづらい物が多々ありますから。 本掲示板に参加させて頂いたのが、つい最近で、それまでずっと、 このように多くの方々が集う場所で、様々なご意見・議論に触れてこなかった私です。 素朴な質問としてお伺いしたいことがございます。 Document-View アーキテクチャに対する世間全般の評価はどのようなものなのでしょうか。 至らない部分があるとして、それはどういった部分なのでしょうか。 これと対比して、では MVC はどうでしょうか。 かなり広範で漠然とした質問となってしまって恐縮です。 何か糸口となる考えや指針などをお聞かせ頂けましたら、と思います。 | ||||
|
投稿日時: 2004-11-16 10:47
たびたび済みません。取り急ぎご報告致します。
私がウダウダと申し上げてきた内容を撤回いたします。 ApplicationContext のヘルプに示されているサンプルソースコード を見て、氷解してしまいました。 MyApplicationContextクラスで様々なことをやっていますね。 現状の NET のフレームワーク内では、ここが肝になるような 気になりました。何を目的とするかに依存する話ですが。 NET 2005 で登場するという Program クラスは、どういうものか よく分かりませんが、しばらくは ApplicationContext に着目して みようと思います。 直前の私の発言に対してのご回答をご用意頂いているとしたら、 本発言も加味した上で頂戴できましたら幸いです。 お騒がせした格好で大変恐縮です。 | ||||
|
投稿日時: 2004-11-16 12:22
大それた機能は何もありません。 static な Main() メソッドを保持するだけのものです。 .NET Framework 2.0 でも MVC, Doc/View を明確にサポートする機能は追加されません。 引き続き「必要な人が自分で実装する」ことになります。 _________________ // 渋木宏明 (Hiroaki SHIBUKI) // http://hidori.jp/ // Microsoft MVP for Visual C# // // @IT会議室 RSS 配信中: http://hidori.jp/rss/atmarkIT/ | ||||
|
投稿日時: 2004-11-16 13:37
>ただ一つ、議論させて頂くポイントになるかと感じましたが、
>ApplicationContext を用いて MVC スタイルを実現するにあたっては、 >Model-View-Controller それぞれの「責務のまっとうが目的であって」、 >「手段の良し悪し」はまずは実現した後の議論、というご発言が気にかかります。 >手段は悪かったとしても、実現をまず優先して目指すべきというご主旨と捉えて >宜しいでしょうか。 いいですよ。 ApplicationContextにとらわれず、MVCにとらわれずで一般論としてです。 達成すべき責務が目の前にあり、取れる手段として気持ち悪い手段しかなければ 気持ち悪い手段でも私は使います。でなければ責務をまっとうできないからです。 簡単に言えば手段が悪くとも他に手段が無ければそれをしなければいけません。 手段的に気持ちわるい部分を内部に隠蔽して上位に気持ちよく動いて貰うのが アーキテクチャの為のフレームワークですよね。 MVCアーキテクチャは.NET Frameworkには実装されていないのでアーキテクチャを 実装しなければなりません、アーキテクチャの実装は独自のフレームワークを構築す る事なので(それが.NET Frameworkの上に乗るとしても)多少の汚れ仕事をする必要 はあります。 独自構築フレームワークの奥底に魑魅魍魎を飼う必要も場合によっては有るでしょう (無いに越したことは無いですが) 魑魅魍魎を避けて通って責務をまっとうしないコンポーネントのもたれあい構造を アプリケーションに持ち込む方向が良いという事はないですよね。 さらには気に入らない部分はファサードによって幾らでも上位アプリケーションに 対して隠せます。 手段をするかしないか、それを上位アプリケーションに対してどう見せるか。これ らは別の話ですよね。 そういう面ではアーキテクチャを実装するという事はアーキテクチャに適合して 動くプログラムの為の必要悪をこなすことです。 「このアーキテクチャはいいのかもしれないけど、結局汚れ仕事は何もしてくれな くて、アプリにまるなげなんだよね」と言われるアーキテクチャを構築したいわけで はないですよね。 ま、ApplicationContextについては理解いただけたようですが、その元の判断に おいてアーキテクチャを実装するって事=必要悪をこなす事という感覚が一般的では 無いのかなと思いましたので書かせてもらいました。 _________________ Microsoft Valueable Professional C# 2004 |