C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[9]: 画面1DLLまたは1画面1EXEって駄目ですか？

(過去ログ 24 を表示中)

[トピック内 18 記事 (1 - 18 表示)]　 << 0 >>

■10934 / inTopicNo.1)

　1画面1DLLまたは1画面1EXEって駄目ですか？

▼■

□投稿者/ やじゅ (5回)-(2007/12/02(Sun) 22:12:58)

分類:[設計/仕様]　

2007/12/03(Mon) 01:05:47 編集(投稿者)
2007/12/03(Mon) 01:05:28 編集(投稿者)

今のプロジェクトは、下記のような構成群(あくまで例)となっております。

言語　VB.Net2005
　共通クラスおよび機能ごと画面作成したもの全てをDLLとする
　ログイン／メニュー画面のみをEXEとする
　　
DLLファイル群
Common 　共通処理(文字列加工、算術処理などのクラス群)
ControlLibrary　継承元フォーム、各基本コントロール
DBAccess　　　　DBアクセス
frmSeikyu　　　請求書入力画面　
frmJuchu　受注入力画面
frmKokyaku 顧客マスタ画面
frmTokuiSearch　得意先マスタ検索画面
…　　　　　　　など
EXEファイル群
frmLoginMenu ログイン/メニュー画面

中さんのブログの中に
プロジェクト分割指針 http://blogs.wankuma.com/naka/archive/2007/10/11/101482.aspx
>1画面1DLLなんて作りはあり得ないことだけは確かで、1画面1EXEなんてあり得ません。

今のプロジェクトは、1画面1DLLで作成しており、外注に頼むにも画面単位で作成をお願い
しています。
1DLLに複数画面にした場合、結合するのが大変(微々ですが)かなと思ってます。

1画面1DLLまたは1画面1EXEって何ゆえ、駄目なんでしょうか？
・メモリ関係？
・ファイル数が多くなるためファイル管理が大変だから？

今後の勉強のためにも、ご教授ください。

引用返信 編集キー/

■10936 / inTopicNo.2)

　Re[1]: 画面1DLLまたは1画面1EXEって駄目ですか？

▲▼■

□投稿者/ よもやま (5回)-(2007/12/02(Sun) 22:33:10)

>
> 画面1DLLまたは1画面1EXEって何ゆえ、駄目なんでしょうか？
> ・メモリ関係？
> ・ファイル数が多くなるためファイル管理が大変だから？
>
1画面1DLLにするときに一番頭を悩ませるのは
各画面とのI/Fだと思います。
コアな部分としては、ＤＢオブジェクトを引きずり回すことになると思いますが
Ａ画面
Ｂ画面と画面が存在する時
Ａ画面からＢ画面を呼び出すこともあれば
Ｂ画面からＡ画面を呼び出すこともある。
となるときＡ画面、B画面がDLL化されているとどのようなＩ／Ｆすべきでしょうか。
あとは、ＤＢ絡むときにはトランザクションの処置でしょうか。

1画面1exeでの考え得る問題点としては
１．ＤＢセッション管理
　ＤＢセッションリソースは有限。
２．編集中データのロークバック場所
　画面中で「キャンセル」ボタンにおける挙動
もしかしたら解決策はあるかもしれません。

#う～む。思いつく範囲がすくないやもしれませんｔ

引用返信 編集キー/

■10937 / inTopicNo.3)

　Re[1]: 画面1DLLまたは1画面1EXEって駄目ですか？

▲▼■

□投稿者/ はつね (361回)-(2007/12/02(Sun) 22:37:40)

■No10934 (やじゅさん) に返信
> 今のプロジェクトは、1画面1DLLで作成しており、外注に頼むにも画面単位で作成をお願い
> しています。
> 1DLLに複数画面にした場合、結合するのが大変(微々ですが)かなと思ってます。

１機能が１画面でおさまっていればいいのではないでしょうか。
私は、機能単位でアセンブリがわかれているのであれば、結果的にそれが１画面であっても良いように思います。

引用返信 編集キー/

■10938 / inTopicNo.4)

　Re[2]: 画面1DLLまたは1画面1EXEって駄目ですか？

▲▼■

□投稿者/ れい (255回)-(2007/12/02(Sun) 23:26:28)

■No10934 (やじゅさん) に返信
> 画面1DLLまたは1画面1EXEって何ゆえ、駄目なんでしょうか？
> ・メモリ関係？
> ・ファイル数が多くなるためファイル管理が大変だから？

私も1画面1DLLでは作りませんが、理由は上記2点ではありません。

確かにDLLやEXEが増えたらオーバーヘッドは増えますが、
相当大きかったり、速度が気になる用途でないかぎり
問題になるほどパフォーマンスは落ちないでしょう。

1画面1DLLで作らないのは、構造化のサイズが違うからです。

DLLやEXEというのは最大レベルに近い構造化で、
あるプロセスがコードを読み込む際の最低単位です。
一方、画面はFormやpageで、GUIの最大単位です。
この二つは一般に一致しません。

一致しない単位で構造化を行うと問題が発生しやすくなります。
それはたくさんの階層で構造化を行う手法であるオブジェクト指向を
少し勉強すればわかると思います。

ですので、「1画面1DLL」という制約は課しません。
もちろん、結果としてそうなる場合もありますが。

引用返信 編集キー/

■10944 / inTopicNo.5)

　Re[3]: 画面1DLLまたは1画面1EXEって駄目ですか？

▲▼■

□投稿者/ Mr.T (126回)-(2007/12/03(Mon) 10:06:41)

Mr.Tです、こんにちは。
#どこにくっつけようか迷ったけど

元々1画面=1Exeにはしない件についての中さんのエントリでは
Ognacさんのエントリで、「受注と発注(だったかな?)画面の使いまわし」
というネタになっていたので、おそらくこういう意味で言ってたと思ってます。
「規約として、1画面1Exeなんてルール、ありえん！」
「画面=Exe Or DLLじゃねーヨ！」

> 1画面1DLLで作らないのは、構造化のサイズが違うからです。
>
> DLLやEXEというのは最大レベルに近い構造化で、
> あるプロセスがコードを読み込む際の最低単位です。
> 一方、画面はFormやpageで、GUIの最大単位です。
> この二つは一般に一致しません。
>
> 一致しない単位で構造化を行うと問題が発生しやすくなります。

この問題っていうのはどういうことでしょうか？
別アセンブリにすることで、開発側で
「同一アセンブリ内だったらよかったのに！ありえへん！」（若しくは、その逆）
が発生するということでしょうか。
それとも、ユーザが具体的に利用する側での問題？
それとも、まったく別の視点？

>それはたくさんの階層で構造化を行う手法であるオブジェクト指向を
>少し勉強すればわかると思います。
スレ主ではないのですが、オブジェクト指向のどういうところから
理解が可能になるのでしょうか？

引用返信 編集キー/

■10947 / inTopicNo.6)

　Re[4]: 画面1DLLまたは1画面1EXEって駄目ですか？

▲▼■

□投稿者/ 中博俊 (1211回)-(2007/12/03(Mon) 10:44:26)

ありとあらゆる事がだめな理由ですが・・・

よもやまさんのいわれていること。
れいさんのいわれていること。
認証をどうやって引き回すのか。
そのEXEに入っている機能はそのEXE固有の物なのか？共通か出来ないのか？
2EXEから別スタートアップする場合どうするの？（本体とマスタメンテナンスがあって、本体からも呼べるけど、単体のマスタメンテ．ＥＸＥもあったり）
層のうちプレゼンだけ細分化する意味はあるのか？（必然的にビジネスロジックやＤＢまで分割してしまっては意味がない。）
というかそもそも画面に固有の機能（ビジネスロジック）を盛り込むわけがないので、ただの抜け殻をばらす必然性がない。
AからBを呼ぶだけだったのが、逆方向もありとなったら循環参照するんですか？

私のDLL分割指針はどっかで書いたけど、層と、汎用かどうか
(System*だけで動くようなクラスとか)などで決めます。
全ての機能はDLLにおしこんで、EXEは署名とコンフィグとスタート画面を起動するだけにします。

辛口っぽく書いてます。ええ。

引用返信 編集キー/

■10948 / inTopicNo.7)

　Re[4]: 画面1DLLまたは1画面1EXEって駄目ですか？

▲▼■

□投稿者/ 渋木宏明(ひどり) (577回)-(2007/12/03(Mon) 10:54:27)

> 元々1画面=1Exeにはしない件についての中さんのエントリでは
> Ognacさんのエントリで、「受注と発注(だったかな?)画面の使いまわし」
> というネタになっていたので、おそらくこういう意味で言ってたと思ってます。

１画面１exe は、単純に「堅固・堅牢な実装が難しくなる」くなるので避けるべきです。

「「Process.Start(), WaitOne() で出来ること」以上のこと」をやろうとすると、たちどころにハマります。

画面（＝exe）間の i/f にどんな技術を用いるか、起動パラメータや処理結果をセキュアにやりとりするためにはどうすればいいのか、などなど、考えるべきことが飛躍的に増大します。

逆に、１画面１exeにすることによって、他のものすごく困難な問題が解決できるんであればそーすればいい（１画面１exeにすることの困難さと秤にかけたうえで）とも思いますが、具体的にどんな問題があるのかちょっと想像できません。

引用返信 編集キー/

■10952 / inTopicNo.8)

　Re[4]: 画面1DLLまたは1画面1EXEって駄目ですか？

▲▼■

□投稿者/ やじゅ (6回)-(2007/12/03(Mon) 11:15:39)

2007/12/03(Mon) 11:24:11 編集(投稿者)

すみません、少しずつコメントを返していきたいと思います。

■No10944 (Mr.T さん) に返信
> Mr.Tです、こんにちは。
> #どこにくっつけようか迷ったけど
>
> 元々1画面=1Exeにはしない件についての中さんのエントリでは
> Ognacさんのエントリで、「受注と発注(だったかな?)画面の使いまわし」
> というネタになっていたので、おそらくこういう意味で言ってたと思ってます。
> 「規約として、1画面1Exeなんてルール、ありえん！」
> 「画面=Exe Or DLLじゃねーヨ！」

とりあえず、元ネタを見つけました→と思ったら違いました、ごめんなさい
Exeに含まれる全部の画面を開始時にインスタンス化するなんて
http://blogs.wankuma.com/ognac/archive/2006/10/09/40984.aspx

引用返信 編集キー/

■10954 / inTopicNo.9)

　Re[5]: 画面1DLLまたは1画面1EXEって駄目ですか？

▲▼■

□投稿者/ 囚人 (245回)-(2007/12/03(Mon) 11:34:15)

ネイティブのDLLの場合は数が増えると、同じアドレスにロードとしようとしたのときのパフォーマンスの著しい低下問題があったので、少ない方が良いっちゃあ良かったですね（何も考えていなかったら、普通は同じアドレスにロードする）。Rebase.exe したら良いんですけど、それを知っている開発者がどれだけいるかって話もあり(Advanced Windows 参照)。

マネージDLLの場合は、Rebase の必要はないですが、万が一 ngen してネイティブ化したい場合は、その問題を考えないとだめなはず（多分）なので、数が増えると面倒ですね（殆どする機会ないけど）。更に言うなら、マネージアセンブリは「本来なら」厳密名をつけ、そして署名して、という手順が必要なので数が多いとかなり面倒かな？と（ぶっちゃけ、律儀に厳密名を付ける気はあまりしないけど）

以上が物理的なファイルの問題。

じゃあ全部一つにした方がいいのかと言えばそんなわけもなく、責任範囲を明確にすべき箇所で分けるべきかなと思います。責任範囲と言っても、開発者の責任の話ではなく、プログラムのスコープの話です。各DLLとEXEのやり取りのインターフェースを明確にし、不必要に他の内部を知る必要がない点では、オブジェクト指向のクラスと同じ考えみたいな感じでしょうか（多分、れいさんの言いたい事はこういう事でしょうか？）。

EXE を別にするというのは、それぞれを別のプロセスとして起動したいかどうかだけであって、それ以上、そしてそれ以外の意味はないかと思います。

引用返信 編集キー/

■10956 / inTopicNo.10)

　Re[4]: 画面1DLLまたは1画面1EXEって駄目ですか？

▲▼■

□投稿者/ れい (256回)-(2007/12/03(Mon) 12:18:45)

■No10944 (Mr.T さん) に返信
> スレ主ではないのですが、オブジェクト指向のどういうところから
> 理解が可能になるのでしょうか？

これ、わかりづらいですね。すみません。
たいしたことではないんですが。

プログラムをしてればわかると思いますが、
構造化はいろいろなレベルで行います。
クラスレベル、ファイルレベル、関数レベル、といったものだけでなく、
コメントも構造化に使いますし、
ファイル中のTABやメンバを書く順番など、そういったものすら構造化に用います。

プログラムの半分は構造化なんです。
うまく構造化できることがいいプログラマの必須条件で、
うまく構造化できる言語がいいプログラム言語の必須条件です。

で、オブジェクト指向も構造化の方法の一つで、最も自由度が高く複雑なものです。
これは様々なレベルで構造化をすることができます。
自由度が高すぎて変な設計をしてしまったりするので、
うまくいく設計を集めてデザインパターンと呼んだりする人もいますよね。

変な設計にもいろいろありますが、
よくあるのが構造化のレベルを間違えた設計です。
全てのデータが一つのクラスのメンバだったり、
メンバが一つしかないクラスが大量にあったり。

慣れてくるとそういうことも少なくなって、
すぐにモデリングできるようになりますよね。

「1画面1DLL」と決めることは、
違うレベルの構造を無理やり一つにまとめることです。
オブジェクト指向で構造化のレベルを間違えたときと
ほぼ同じ状況にみえませんか？

ということだったんですが。

> この問題っていうのはどういうことでしょうか？

本棚には本があり、飛行場には飛行機があるものです。
本棚にセスナがあったり、滑走路に本が並べてあるのは変です。

不具合はいろいろ考えられますが、
前提がおかしすぎるので、どんな不具合を考えても、意味がわかりません。

#本棚にセスナが置けるなら大きすぎて本を探すの大変だろ、とか。
#滑走路は屋外なので本が濡れちゃって困る、とか。

それと同じです。

構造化のレベルが違うものは、まとめることを考慮しません。
具体的にどんな問題が生じるのか、考慮する必要もありません。

なんで本棚にセスナを置いちゃいけないのと聞かれても、困ります。
具体的な問題を聞かれても、多すぎて困ります。

まとめると、
> 1画面1DLLまたは1画面1EXEって何ゆえ、駄目なんでしょうか？
「画面とDLLでは構造化のレベルが違うから」ということになります。

引用返信 編集キー/

■10957 / inTopicNo.11)

　Re[5]: 画面1DLLまたは1画面1EXEって駄目ですか？

▲▼■

□投稿者/ Mr.T (128回)-(2007/12/03(Mon) 12:21:28)

2007/12/03(Mon) 12:27:22 編集(投稿者)

> 画面（＝exe）間の i/f にどんな技術を用いるか、起動パラメータや処理結果をセキュアにやりとりするためにはどうすればいいのか、などなど、考えるべきことが飛躍的に増大します。

考えること（すべきこと）が増えてしまうのは確かにいやです。

> 逆に、１画面１exeにすることによって、他のものすごく困難な問題が解決できるんであればそーすればいい（１画面１exeにすることの困難さと秤にかけたうえで）とも思いますが、具体的にどんな問題があるのかちょっと想像できません。

一回しか使わない単体機能のツール類のもんくらいなら、1Exeでもええんじゃないかな、と。
#実際私は、そういうのが多いけど。

引用返信 編集キー/

■10958 / inTopicNo.12)

　Re[6]: 画面1DLLまたは1画面1EXEって駄目ですか？

▲▼■

□投稿者/ れい (257回)-(2007/12/03(Mon) 12:28:29)

■No10954 (囚人さん) に返信
> じゃあ全部一つにした方がいいのかと言えばそんなわけもなく、責任範囲を明確にすべき箇所で分けるべきかなと思います。責任範囲と言っても、開発者の責任の話ではなく、プログラムのスコープの話です。各DLLとEXEのやり取りのインターフェースを明確にし、不必要に他の内部を知る必要がない点では、オブジェクト指向のクラスと同じ考えみたいな感じでしょうか（多分、れいさんの言いたい事はこういう事でしょうか？）。

そうそう。そうです。

クラスを使ったり、ファイルを使ったり、DLLを使ったり。
用途によって適切なレベルで構造化を行うべきです。

「1画面1DLL」を課すのは、
「ソースファイルは各プロジェクトに一つ。全てのコードはそのファイルに書くこと」とか
「各業務ごとに1台のPCを用意すること」とか
そういう規約と同値です。

できなくはないけど馬鹿らしいなぁと。
具体的な問題を考える意味は無いと思います。

引用返信 編集キー/

■10959 / inTopicNo.13)

　Re[5]: 画面1DLLまたは1画面1EXEって駄目ですか？

▲▼■

□投稿者/ Mr.T (129回)-(2007/12/03(Mon) 12:37:44)

> 「1画面1DLL」と決めることは、
> 違うレベルの構造を無理やり一つにまとめることです。
> オブジェクト指向で構造化のレベルを間違えたときと
> ほぼ同じ状況にみえませんか？
>
> ということだったんですが。

なるほど、似たような構造を持った間違いという意味だったのですね。

> まとめると、
>>1画面1DLLまたは1画面1EXEって何ゆえ、駄目なんでしょうか？
> 「画面とDLLでは構造化のレベルが違うから」ということになります。

やじゅさんが、具体的な話を求めていたのか、一般論な話を求めていたのか
わかりませんけど、皆さんが指摘されているような、Exe間I/Fは大丈夫？
ってのが一つのキーになりそうな感じですね。

引用返信 編集キー/

■10962 / inTopicNo.14)

　Re[5]: 画面1DLLまたは1画面1EXEって駄目ですか？

▲▼■

□投稿者/ れい (258回)-(2007/12/03(Mon) 12:45:30)

あ、そうそう。

exeの場合はプロセスと結びついてるという制約がありますのでdllと多少違います。
ですから、

■No10947 (中博俊さん) に返信
> 私のDLL分割指針はどっかで書いたけど、層と、汎用かどうか
> (System*だけで動くようなクラスとか)などで決めます。
> 全ての機能はDLLにおしこんで、EXEは署名とコンフィグとスタート画面を起動するだけにします。

私もほぼ同じで、exeはスタートアップ用です。
プロセスと機能は関係ないものですから。

#小さいプロジェクトのときはめんどくさいのでexe一個ですが。

引用返信 編集キー/

■10970 / inTopicNo.15)

　Re[6]: 画面1DLLまたは1画面1EXEって駄目ですか？

▲▼■

□投稿者/ 渋木宏明(ひどり) (583回)-(2007/12/03(Mon) 14:37:08)

>Rebase.exe したら良いんですけど、

いや、それも考えものなんです。

どのバージョンだったか忘れましたが、ひと昔前の M$IME が「かっとんだ」初期アドレスを指定してやがったよーで、数値計算用に大規模なメモリ確保を行うアプリが、英語版ＯＳでは問題無く動作するのに、日本語版ＯＳでは VritaulAllocEx() に失敗する、という事例を耳したことがあります。

# 幸運にも、目にはしないで済みました (^^;

引用返信 編集キー/

■10974 / inTopicNo.16)

　Re[7]: 画面1DLLまたは1画面1EXEって駄目ですか？

▲▼■

□投稿者/ 囚人 (246回)-(2007/12/03(Mon) 14:58:29)

>どのバージョンだったか忘れましたが、ひと昔前の M$IME が「かっとんだ」初期アドレスを指定してやがったよーで、数値計算用に大規模なメモリ確保を行うアプリが、英語版ＯＳでは問題無く動作するのに、日本語版ＯＳでは VritaulAllocEx() に失敗する、という事例を耳したことがあります。

事情は分かりませんが、超推測でIME擁護しちゃうと「数値計算用に大規模なメモリ確保を行うアプリ」が、「俺は rebase してるから再配置なんて絶対必要ないズェ」とかいう理由で、再配置無効でビルドしちゃったとか。と思ったけど、それだとロードができませんね。

引用返信 編集キー/

■10986 / inTopicNo.17)

　Re[8]: 画面1DLLまたは1画面1EXEって駄目ですか？

▲▼■

□投稿者/ 黒龍 (91回)-(2007/12/03(Mon) 18:57:34)

だめな点は確かに多いですね。
が、割とビギナーよりな方から良く出る質問だったりもします。新人さんに聞かれたら「社員旅行に行く場合一人一台ずつ車で行くのは無駄が多いっしょ？話もやりにくいしさ。バスで行くとかするよね。」と答えてます。
も少し慣れてきたらリリースの単位だとかそのあたりのお話をやりますが最初はざっくりと答えて済ましちゃってますね。

引用返信 編集キー/

■10995 / inTopicNo.18)

　Re[9]: 画面1DLLまたは1画面1EXEって駄目ですか？

▲▼■

□投稿者/ やじゅ (7回)-(2007/12/04(Tue) 00:12:06)

2007/12/04(Tue) 00:18:24 編集(投稿者)

コメントして頂いたみなさま、ありがとうございます。
まとめコメントとなりますが、お許しください。

以前のプロジェクトでは、1画面1EXEとなっており、その場合だとI/Fの融通性が利かない
(コマンドラインによるパラメータ渡し、DBコネクションなど引き継ぎにくいなど）があり
今回のプロジェクトでは、メニュー以外はDLLとしました。
その方式で製作していた中で、中さんのプロジェクト分割指針を読んで、迷いが生じたため
今回、質問させていただきました。

>1画面1DLLなんて作りはあり得ないことだけは確かで、1画面1EXEなんてあり得ません。
まず、私はこの言葉をそのままの解釈で受け取っていたわけですが、その背景として
規約として、1画面1DLL(EXE)と課して制限しているがそもそもおかしいってことを
言われていたわけですね。　

>クラスを使ったり、ファイルを使ったり、DLLを使ったり。
>用途によって適切なレベルで構造化を行うべきです。
れいさんの仰るように、適切なレベルで構造化したとして、
結果的にそれが１画面となっても、それはそれで問題ないと私的には理解しました。

今回は大変勉強になりました、ありがとうございますm(_ _)m

解決済み

引用返信 編集キー/

トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

- Child Tree -