- PR -

画面が多数ある場合のプロジェクト生成方法について

1|2 次のページへ»
投稿者投稿内容
ガーリック
常連さん
会議室デビュー日: 2005/05/24
投稿数: 22
投稿日時: 2006-01-16 18:57
画面数が５０以上はありそうなんですが、以下の方法が考えられると思います。
１）全画面１プロジェクトとして生成
２）１画面１プロジェクトし画面数分のプロジェクトとして生成
３）関連性のある画面を１つにまとめて、複数のプロジェクトとして生成

単純に考えれば、１）だと思うのですが、リソースをどれだけくうか分からないこと、実装するマシンのスペックも分からないことから、１つのプロジェクトにまとめるのは危ないのではないかと危惧しています。
（実装したアプリは、メニュー画面から詳細メニューへと遷移していきますが、メニュー画面が複数（３つ、４つほど）起動できるようにしないといけません）

ただ、プロジェクトを分けた場合、画面どうしでの入出力情報のやりとりを行うために、何かしらの実現方法を考えなければいけません。
共有メモリなどを使用する方法はないかと考えていますが、それ以外にも何かしらいい方法はないかと模索している段階です。

いい実現方法はないでしょうか？


[ メッセージ編集済み 編集者: ガーリック 編集日時 2006-01-16 18:58 ]
かるあ
ぬし
会議室デビュー日: 2003/11/16
投稿数: 1190
お住まい・勤務地: センガワ→ムサシノ
投稿日時: 2006-01-16 19:11
引用:

画面数が５０以上はありそうなんですが、以下の方法が考えられると思います。
１）全画面１プロジェクトとして生成
２）１画面１プロジェクトし画面数分のプロジェクトとして生成
３）関連性のある画面を１つにまとめて、複数のプロジェクトとして生成


僕は大体 3 の方法でソリューションを作成しています。


引用:

ただ、プロジェクトを分けた場合、画面どうしでの入出力情報のやりとりを行うために、何かしらの実現方法を考えなければいけません。
共有メモリなどを使用する方法はないかと考えていますが、それ以外にも何かしらいい方法はないかと模索している段階です。

共通のプロパティにデータを渡すように実装するのかな
（インターフェイスの出番ですね）
甕星
ぬし
会議室デビュー日: 2003/03/07
投稿数: 1185
お住まい・勤務地: 湖の見える丘の上
投稿日時: 2006-01-16 19:20
2)は.NETアプリケーションでは非現時的になるかと思います。.NETアプリケーションは起動時のオーバーヘッドが大きいのは周知の事実です。画面単位でプロセスを分割してしまうと、パフォーマンス的に無理があると思います。DLLとしてプロジェクトを分離する方法もあるかと思いますが、この場合もファイル管理コストばかり跳ね上がってしまう予感がします。

というわけで１）か３）ですね。３）の場合にはお互いに関連性の低い画面をひとつのプロセスに纏めます。分離できないほど密な関係にあるなら、必然的に１）になりますね。
ガーリック
常連さん
会議室デビュー日: 2005/05/24
投稿数: 22
投稿日時: 2006-01-16 19:39
かるあさん、甕星さん　さっそくの回答ありがとうございます。

お二人とも２）の方法は実現的でないという共通のご意見でした。
リソース不足が一番、心配をしておりますが、その辺りの観点から考えますと、
１プロジェクトにすることでの不安要素はないでしょうか？

３）で実現する場合は、画面ＩＤ、ユーザＩＤなどの情報を渡す必要があるため、
それをどうやって実現するかがキーになると考えています。
ｘｍｌファイルを作成し、それに書き込んでいく方法が一般的なのかと思いますが、ほかにいい方法があれば、教えて頂きたいと思います。
囚人
ぬし
会議室デビュー日: 2005/08/13
投稿数: 1019
投稿日時: 2006-01-16 20:18
「プロジェクト」という単位を「別プロセス」として扱うということでしょうか？
それぞれ複数の画面が「別プロセス」として扱われるのならば、プロジェクトを複数にする２）と３）はより多くのリソースを食う事になるでしょう。
しかし、「プロジェクト」を「別プロセス」として考えているわけではない、というのならば（つまり DLL にする事ですが）、その限りではないでしょう。

ワザワザ別のプロセスにする必要もないのであれば、
引用:

３）で実現する場合は、画面ＩＤ、ユーザＩＤなどの情報を渡す必要があるため、
それをどうやって実現するかがキーになると考えています。
ｘｍｌファイルを作成し、それに書き込んでいく方法が一般的なのかと思いますが、ほかにいい方法があれば、教えて頂きたいと思います。

これも簡単でしょう。

# 「共有メモリ」というワードが出てきているので、別プロセスにするのかな？

_________________
囚人のジレンマな日々
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2006-01-16 21:08
引用:

ガーリックさんの書き込み (2006-01-16 19:39) より:

リソース不足が一番、心配をしておりますが、その辺りの観点から考えますと、
１プロジェクトにすることでの不安要素はないでしょうか？

すべて同時に利用するような仕様なのでしょうか?
通常はリソース不足の心配は要りません。
CLR は必要な時に初めてアセンブリからモジュールをロードします。

引用:

３）で実現する場合は、画面ＩＤ、ユーザＩＤなどの情報を渡す必要があるため、
それをどうやって実現するかがキーになると考えています。

ログイン機能をどこに配置するかにも因りますね。
認証できる構成であるならば、最悪コマンドライン引数でもできます。
あとは、AppDomain を使って渡してみるとか、色々方法はありますね。

引用:

ｘｍｌファイルを作成し、それに書き込んでいく方法が一般的なのかと思いますが、ほかにいい方法があれば、教えて頂きたいと思います。

セキュリティなども考えてくださいね。(^-^;)

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
lalupin4
大ベテラン
会議室デビュー日: 2004/07/26
投稿数: 163
投稿日時: 2006-01-17 00:28
引用:

１）全画面１プロジェクトとして生成
２）１画面１プロジェクトし画面数分のプロジェクトとして生成
３）関連性のある画面を１つにまとめて、複数のプロジェクトとして生成

　迷わず３）。

引用:

いい実現方法はないでしょうか？

　山ほどある。以下に一部を：

Buschmann, Frank=Meunier, Regine=Rohnert, Hans=Sommerland, Peter=Stal, Michael
「Model-View-Controller」
『ソフトウェアアーキテクチャ ソフトウェア開発のパターン体系』
2000年 近代科学社 pp120-139
http://www.amazon.co.jp/exec/obidos/ASIN/4764902834/

Gamma, Eric=Helm, Richard=Johnson, Ralph=Vlissides, John
「Mediator」
『オブジェクト指向における再利用のためのデザインパターン』改訂版
1999年 ソフトバンクパブリッシング pp291-302
http://www.amazon.co.jp/exec/obidos/ASIN/4797311126/

Fowler, Martin
「アプリケーションコントローラ」
『エンタープライズアプリケーションアーキテクチャパターン』
2005年 翔泳社 pp403-410
http://www.amazon.co.jp/exec/obidos/ASIN/4798105538/
渋木宏明(ひどり)
ぬし
会議室デビュー日: 2004/01/14
投稿数: 1155
お住まい・勤務地: 東京
投稿日時: 2006-01-17 00:30
引用:

通常はリソース不足の心配は要りません。
CLR は必要な時に初めてアセンブリからモジュールをロードします。


ただし、現状アンロードすることが出来ないので、あまりにも資源を浪費するようなつくりの場合、困ることも考えられます。

ですが、５０画面全部がホントに関連しあうのかなぁ？

十数〜数十画面くらいの規模にグルーピングできてもよさそうな気がしますが。。。
1|2 次のページへ»

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