- PR -

MVCモデルをWindowsFormで適用するのは正しいのでしょうか？

1|2 次のページへ»
投稿者投稿内容
フォルテッシモ
会議室デビュー日: 2003/12/04
投稿数: 12
投稿日時: 2003-12-04 12:00
いつも拝見させていただいております。
.NET C#初心者です。宜しくお願いします。考えが煮詰まってしまって
先輩方の考えをお聞きしたく書き込みをしました。

今お勉強用にアプリケーションを一つ作っています。
メインフォームがあり、サブダイアログを２つ持っているアプリケーションです。

これを生成するにあたり JAVAのWebで適用していたMVCモデルを適用しようと
安直に考えました。

MVCモデルは
M ビジネスロジック
V WindowForm
C 制御用CLASS

の３つに相当すると考えました。

最初にMainFormのフォームオブジェクトは　サブフォーム２枚を持っている
と考え MainFormのフォームオブジェクトにサブフォームのインスタンスを
持たせました。

ここからMVCにあてはめようと思った時にMは元から分離されてたんですが VとCが
切り離せません。

MainFormがサブフォームのインスタンスを持っている為
別クラスにコントロールを持ってそのサブフォームを制御するのが意味がない
ような気がしてきました。

今はMainFormにサブフォームを持たせてしまってはいけないのかなぁっと思っております。
実際サブフォームのインスタンスを持たせるのは Controlクラス？でしょうか

実際GUIアプリケーションを生成されてる方はどのような設計されてるのか
何か根本的にそれは違うよや　これを見て再度勉強しなさい　などのご意見が
お聞き出来たら幸いです。

宜しくお願いします。
ぽん
大ベテラン
会議室デビュー日: 2003/05/13
投稿数: 157
投稿日時: 2003-12-04 13:02
.NET C#は全く知らないのですが･･･

引用:

フォルテッシモさんの書き込み (2003-12-04 12:00) より:

MainFormがサブフォームのインスタンスを持っている為
別クラスにコントロールを持ってそのサブフォームを制御するのが意味がない
ような気がしてきました。

今はMainFormにサブフォームを持たせてしまってはいけないのかなぁっと思っております。
実際サブフォームのインスタンスを持たせるのは Controlクラス？でしょうか

以下の様にしてみてはいかがでしょう？(MVCではなくて、PACですが)
コード:

[MainView]<-[MainController]->[MainModel]

　　　　　　　　　↓

[SubView]<-[SubController]->[SubModel]


引用:

実際GUIアプリケーションを生成されてる方はどのような設計されてるのか
何か根本的にそれは違うよや　これを見て再度勉強しなさい　などのご意見が

僕はアプリケーションを作る場合(GUIに限らず)、基本的にPACパターンを用いて作成してます。(MVCパターンも部分的には使用)
MVCよりPACの方が、しっかりしたものが出来ますので。

アーキテクチャパターンを学ぶなら、この本がお勧めです
http://www.amazon.co.jp/exec/obidos/ASIN/4764902834/250-9246785-1831450

[追記]
タイトルの回答に全くなっていなかったですね...

[ メッセージ編集済み 編集者: ぽん 編集日時 2003-12-04 13:07 ]
よねＫＥＮ
ぬし
会議室デビュー日: 2003/08/23
投稿数: 472
投稿日時: 2003-12-04 13:49
> ここからMVCにあてはめようと思った時にMは元から分離されてたんですが VとCが
> 切り離せません。

Windowsアプリを作るときは、モデル(M)とビュー(V)にしか分けません。
ビューがコントローラを兼ねる形で無理に分ける必要はないと思います。

> MainFormがサブフォームのインスタンスを持っている為
> 別クラスにコントロールを持ってそのサブフォームを制御するのが意味がない
> ような気がしてきました。

私も同じように考えてます。
WindowsアプリはWindowsのコントロールの仕様、制限に
強く影響されるのでどのみち奇麗に切り分けできないですし。
フォルテッシモ
会議室デビュー日: 2003/12/04
投稿数: 12
投稿日時: 2003-12-05 00:04
よねＫＥＮさん　ぽんさん　お答えありがとうございます。
やはり　難しいんですね。WindowsFormアプリケーションに適用するには。
悩んでいたので　ちょっとすっきりしました。ネットで探しても適用例
がさっぱり見当たらないので＾＾；；；.NETペットショップのコメントも
MVCモデル否定的で悩んでました。

PACパターンは全然知りませんでした。
[MainView]<-[MainController]->[MainModel]
　　　　　　　　　↓
[SubView]<-[SubController]->[SubModel]
教えていただき本当にありがとうございます！！本を買ってみようと
思います。

これは　Controller同士が　通信するという理解でいいんですか？

お返事本当にどうもありがとうございました。


[ メッセージ編集済み 編集者: フォルテッシモ 編集日時 2003-12-05 08:43 ]
ぽん
大ベテラン
会議室デビュー日: 2003/05/13
投稿数: 157
投稿日時: 2003-12-05 09:58
引用:

フォルテッシモさんの書き込み (2003-12-05 00:04) より:

これは　Controller同士が　通信するという理解でいいんですか？

そうです。
(本当はPACの場合、「Controller」ではなくて「Control」ですけど)

MVCとPACの違いなどはこちらを参考にして下さい。
http://www.mamezou.com/tec/Tips/umlForumJp2001/umlArchi.html
http://www.asahi-net.or.jp/~dp8t-asm/java/articles/OOAD/article.html#id_1243_
フォルテッシモ
会議室デビュー日: 2003/12/04
投稿数: 12
投稿日時: 2003-12-08 09:54
ぽんさん　お返事どうもありがとうございます＾＾
PACパターンを読ませて頂き考えてみました。

未熟ですが自分なりに考えてみました。

WindowsForm設計にあてはめると

Presentation Control 　　　　Abstractopn
WindowForm 制御コントローラ WindowFormロジック,モデルクラス
ということになるんですね。

実際のソースで考えました。
MAINFORMでボタンが押下された場合にSUBFORMを開いて渡されたデータを表示する場合

1.MAINFORMからMAINFORM 制御コントローラクラスを生成
（またはMAINFORMの生成時に持っておいて使いまわす)

2.MAINFORM 制御コントローラクラスを叩く

3.MAINFORM 制御コントローラクラスが
　サブウィンドウ 制御コントローラクラスを生成

4.サブウィンドウ 制御コントローラクラスが
　サブウィンドウインスタンスを生成

5.サブウィンドウ 制御コントローラクラスが
　サブウィンドウメソッドを実行

の手順になると考えました。うーんちょっと複雑かな？

WindowsFormを生成すると
一番最初にキックされるのは実はメインフォームのPresentation
なんです。（VisualStudioでWindowsアプリケーションを生成した場合）
それが自分の中ですごくひっかかっていて MVCを適用しようと思った時に
なんか変だと書き込む前に思ってました。最初にVがキックされるのかって。

でも皆さんのお話を伺い　自分でもう一度考えてみて
そのソースもWindowsFormも結局　自分自身を実行してnewしてそれを
WindowsForm自体がやっぱ制御コントローラという考えにするとつじつまがあうのかな
っと思いました。

MainForm.csの中身

static void Main()
{
Application.Run(new MainForm());
}


WindowsFormはViewとControlを兼ねている。

結論としてWindowsFormでの設計はM-VCモデルがいいのかなぁっと思いました。
M-VC←→CV-M
VC=V+C=Windows.Form
これだとPACパターンにもあてはまるし（強引ですが＾＾；）

よねKENさんと同じ　VCは別ける必要はない　と考えました。駄目ですかね＾＾；？
でもこのような考える機会をあたえてくださって本当にありがとうございました。
ぽん
大ベテラン
会議室デビュー日: 2003/05/13
投稿数: 157
投稿日時: 2003-12-08 10:46
引用:

フォルテッシモさんの書き込み (2003-12-08 09:54) より:

WindowsForm設計にあてはめると

Presentation Control 　　　　Abstractopn
WindowForm 制御コントローラ WindowFormロジック,モデルクラス
ということになるんですね。

正しくは
Presentation:WindowForm,WindowFormロジック(画面の制御)
Control :制御コントローラ,モデルクラス(ビジネスロジック)
Abstractopn :永続的なデータ
です。
[画面]<-[ロジック]->[データ]
という分け方です。
(画面とデータを完全に切り分けているのもPACの特徴です)

前々回の例えが悪かったですね 。
(MVCとPACを混同するような書き方をしてしまいました)
コード:
前々回の例え
[MainView]<-[MainController]->[MainModel]
　　　　　　　　　↓
[SubView]<-[SubController]->[SubModel]



引用:

実際のソースで考えました。
MAINFORMでボタンが押下された場合にSUBFORMを開いて渡されたデータを表示する場合

1.MAINFORMからMAINFORM 制御コントローラクラスを生成
（またはMAINFORMの生成時に持っておいて使いまわす)

2.MAINFORM 制御コントローラクラスを叩く

3.MAINFORM 制御コントローラクラスが
　サブウィンドウ 制御コントローラクラスを生成

4.サブウィンドウ 制御コントローラクラスが
　サブウィンドウインスタンスを生成

5.サブウィンドウ 制御コントローラクラスが
　サブウィンドウメソッドを実行

の手順になると考えました。うーんちょっと複雑かな？

PACのメリットとしては、
サブウィンドウが今後増える場合や、
サブウィンドウが複数有り、互いに連携する場合などに、
画面同士が切り離されていることによって、
変更を他の画面に依存しない形で行う事が出来ます。
逆にいえば、サブウィンドウが一つ又は少数の場合は
PACを用いるデメリットの方が大きくなるかもしれません。
(無意味に複雑になるということですね)


引用:

WindowsFormはViewとControlを兼ねている。

結論としてWindowsFormでの設計はM-VCモデルがいいのかなぁっと思いました。
M-VC←→CV-M
VC=V+C=Windows.Form
これだとPACパターンにもあてはまるし（強引ですが＾＾；）

よねKENさんと同じ　VCは別ける必要はない　と考えました。駄目ですかね＾＾；？

いえ、良いと思いますよ 。
合わないパターンを無理に使う必要は無いですかね。
(余談ですが、「M-VC」の形だと「Document - View アーキテクチャ」というパターンが有ります)

引用:

でもこのような考える機会をあたえてくださって本当にありがとうございました。

誰かとアーキテクチャパターンの議論をしてみたいなーっと思っていたのでつい口を出してしまいました。
(あまり的を射ない回答で失礼しました )
ナキヲ
常連さん
会議室デビュー日: 2003/08/22
投稿数: 32
お住まい・勤務地: 京都・自宅から勤務地まで自転車で４０分
投稿日時: 2003-12-08 11:05
話は少しそれるかもしれませんが、

引用:

static void Main()
{
Application.Run(new MainForm());
}


Application.Runにはformを引数にとらない、
引数無しのバージョンがあります。

コード:

FormMain form = new FormMain();

form.Show();

System.Windows.Forms.Application.Run();


Formを引数にとるRun()はそのFormのClosedイベントに
Application.ExitThreadを呼び出すハンドラを追加します。
引数無しのRun()では、これが行われないので、
Form.Show()したFormから自分でExit/ExitThreadを呼び出さないと
Run()から抜けられなくなります。
(Run()はWinAPI直でコーディングしているときの
メッセージループ処理に相当する部分を行っています）

私も、Form作成より前にコントロールObjectを作って
そこからはじめようと試みかけていたのですが、
画面が少ないため複雑になりすぎる感があったのでやめました。
画面数の少ないWindowsFormではM-VCが単純でよいのかもしれません。

[ メッセージ編集済み 編集者: ナキヲ 編集日時 2003-12-08 11:07 ]
1|2 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）