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

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

ログ内検索

キーワードを複数指定する場合は半角スペースで区切ってください。
検索条件は、(AND)=[A かつ B] (OR)=[A または B] となっています。
[返信]をクリックすると返信ページへ移動します。

キーワード	/	検索条件	/
検索範囲	/	強調表示	/ ON (自動リンクOFF)
結果表示件数	/	記事No検索	/ ON
大文字と小文字を区別する

No.1778 の関連記事表示

ヒット / 20件

<< 0 >>

■1778

　アプリケーション作成時に機能別にexeを分けていますか？

□投稿者/ ばこま -(2007/03/06(Tue) 10:14:31)

分類:[Windows 全般]　

2007/03/06(Tue) 10:14:51 編集(投稿者)

こんにちは、ばこまです。連続投稿失礼します・・・

今C#にて画面が４０個程度のWindowsアプリケーションを作成していますが、色々調べてみたら
exeを機能別に分けている方法が多いような気がします。
exeを機能別に分けるメリット、デメリットとは何でしょうか？

個人的には分けない方がデータの受け渡し、画面起動がスムーズに行えるような気がしますが…

それではよろしくお願いします。

親記事 /過去ログ10より / 関連記事表示
削除チェック/

■1780

　Re[1]: アプリケーション作成時に機能別にexeを分けていますか？

□投稿者/ M.K -(2007/03/06(Tue) 10:37:46)

■No1778 (ばこまさん) に返信

> exeを機能別に分けるメリット、デメリットとは何でしょうか？

機能別に全部exeにしてしまうとばこまさんの仰る様にデータの受け渡しや画面起動
の点でちょっと大変かも知れませんが、メニューなどから起動されるメイン画面のみ
exeとし、そこから呼ばれるサブ画面などはdllにする事でその辺りの問題は改善され
ると思います。

その上で個人的にパッと思いつくメリット・デメリットです。

メリット：

　多人数で並列して開発が出来る。
　機能毎にモジュールの処理が完結しているので再利用性が高い。
　加修を行った際に他のモジュールへの影響度合いが低い。
　１アセンブリのファイルサイズを小さくする事が出来る。

デメリット：

　作り方によっては起動時のオーバーヘッドが大きくなる。
　個々のアセンブリのバージョン管理が必要になる。
　ファイル数が多くなるので、プログラム名やソースなど管理が大変になる。
　参照設定が複雑になり過ぎてかえって加修時の影響度が大きくなる場合もある。

それぞれに一長一短があると思うので、開発規模や開発ルールに則ってどちらが
良いかを選択すればよいかと思います。

記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1783

　Re[2]: アプリケーション作成時に機能別にexeを分けていますか？

□投稿者/ 未記入 -(2007/03/06(Tue) 11:28:03)

■No1780 (M.K さん) に返信
> 　ファイル数が多くなるので、プログラム名やソースなど管理が大変になる。
> 　参照設定が複雑になり過ぎてかえって加修時の影響度が大きくなる場合もある。

これはありえないかなぁ。
ファイル数が多くなるのと、ソースが複雑になるのとではわけが違うのでデメリットになるのかな。と。

バージョン管理については、どこにいってもデグレードさせる人がいるので、VSSで管理します。
というより、VSSで管理しておけばあまり問題にならないでしょう。

あとの意見は概ね賛成。
データの受け渡しに関しては、RDBMSなどで行えばいいでしょう。

小規模でもない限り分けた方が良いに１票。

記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1798

　Re[3]: アプリケーション作成時に機能別にexeを分けていますか？

□投稿者/ 中博俊＠ -(2007/03/06(Tue) 19:18:41)

EXEを画面単位にわけるってこと？
おいらは反対。
EXEは1つでやるべき。
DLLは好きにしてちょ。

よく認証、認可でメニューを切り替えますとか言って、メニューEXEにしか対策されていなくて、単独EXE起動すれば使えるとかお茶目なアプリがあったりします。

もちろんEXEが分かれているとプロセスが分離するので、データのやり取りが大変ってのがありますね。

EXEはあくまでエントリポイントとしての分割単位にとどめたほうがいいと思います。

記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1801

　Re[4]: アプリケーション作成時に機能別にexeを分けていますか？

□投稿者/ はつね -(2007/03/06(Tue) 21:12:58)

Windows全般という事ですが、私の場合は.NET以降かでちょっとだけ異なります。

基本は機能単位にアセンブリを作るという事です。

ただし、VB6までの場合はアセンブリ=EXEにしています。このとき注意していたのは単独で起動されたとしても問題ない範囲でEXEを分けることでした。
.NETでは、もう少し柔軟にしており、起動する部分はEXEでそれ以降はDLLになっていたりもします。

アセンブリが増えるとコンパイル時間などの問題もあるでしょうが、修正したファイルが含まれるプロジェクトだけコンパイルすればいいのですから、実際はアセンブリの数というよりも再コンパイルが必要な範囲に依存すると思います。きちんと設計すればするほど影響範囲が狭まりますから、コンパイル時間を気にしてアセンブリを分けるのを躊躇する必要はないと考えます。

記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1799

　Re[1]: アプリケーション作成時に機能別にexeを分けていますか？

□投稿者/ Hirotow -(2007/03/06(Tue) 20:03:42)

どうでもいいことですが、EXEやDLLの数、すなわちプロジェクトの数がふえるほどビルドの所要時間は増加します。
またプロジェクトに改名の必要が生じたときが面倒です（そんなことしないのが一番ですが）。

駄文ですみません。

記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1800

　Re[2]: アプリケーション作成時に機能別にexeを分けていますか？

□投稿者/ Ognac -(2007/03/06(Tue) 20:21:24)

目の前のプロジェクトで関連する不具合が発生してます.
100画面程度のアプリを 5つのサブシステムに別けて、各サブシステムを一つのプロジェクト(.DLL型)にしています。
EntryPointのMenu.exeから,各DLLを参照し画面遷移する仕組み。
画面遷移の方向にもよりますが、この場合は、プロジェクトは　.exeプロジェクトであるべきでしょう。
案の定, Sub_AからSub_Bに移り,Sub_BからSub_Aに戻る必要がてぎた時に,相互参照でコンパイルエラーになってました。
至って初歩的な不具合なんですが、陥りがちです。
業務アプリでは, SUBシステム単位で .EXEであるべきというのが, 私の主張です。

記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1802

　Re[3]: アプリケーション作成時に機能別にexeを分けて

□投稿者/ ばこま -(2007/03/06(Tue) 21:51:27)

2007/03/07(Wed) 12:11:11 編集(投稿者)

みなさん貴重なご意見ありがとうございます。
結局は一長一短で規模別に型にはまらず柔軟に使い分けが良さそうですね。

大変勉強になりました、ありがとうございます。

記事No.1778 のレス / END /過去ログ10より / 関連記事表示
削除チェック/

■1813

　Re[3]: アプリケーション作成時に機能別にexeを分けていますか？

□投稿者/ 渋木宏明(ひどり) -(2007/03/07(Wed) 03:29:32)

2007/03/07(Wed) 03:33:32 編集(投稿者)

■No1800 (Ognac さん) に返信
> 画面遷移の方向にもよりますが、この場合は、プロジェクトは　.exeプロジェクトであるべきでしょう。
> 案の定, Sub_AからSub_Bに移り,Sub_BからSub_Aに戻る必要がてぎた時に,相互参照でコンパイルエラーになってました。
> 至って初歩的な不具合なんですが、陥りがちです。

それ「だけ」が問題であるなら、比較的簡単な作りこみで回避できるんじゃないですかね？

既に出ている話ですが、プロセスを分割することによってデータ交換の手間が増大し、安易な作りこみによってデータ漏洩などのセキュリティ低下を招くリスクの方が個人的には心配です。

まぁこれも適当なフレームワークを作ってあげれば回避は可能ですが、穴の無いものに仕上げるには意外と苦労します。

記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1814

　Re[3]: アプリケーション作成時に機能別にexeを分けていますか？

□投稿者/ Jitta -(2007/03/07(Wed) 07:27:10)

■No1800 (Ognac さん) に返信
> 画面遷移の方向にもよりますが、この場合は、プロジェクトは　.exeプロジェクトであるべきでしょう。
> 案の定, Sub_AからSub_Bに移り,Sub_BからSub_Aに戻る必要がてぎた時に,相互参照でコンパイルエラーになってました。
それは別の問題でしょう。
画面の主従関係が整理されていないため、と思います。

記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1822

　Re[4]: アプリケーション作成時に機能別にexeを分けていますか？

□投稿者/ Ognac -(2007/03/07(Wed) 10:26:04)

■No1814 (Jitta さん) に返信
>画面の主従関係が整理されていないため、と思います。
画面遷移を一方通行で構築する範囲では, DLLで構築するほうが,利便性が高いし,薦めるのでが、
相互に画面を呼び合ったり,ループ状に参照しあったりするケースで,整理できないまま,具合の悪い面を残したまま製造が上がって来るので,予防の意味もあり、そう言っています。(私のチェック怠慢もあります)

記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1823

　Re[5]: アプリケーション作成時に機能別にexeを分けていますか？

□投稿者/ 渋木宏明(ひどり) -(2007/03/07(Wed) 10:32:27)

■No1822 (Ognac さん) に返信
> 相互に画面を呼び合ったり,ループ状に参照しあったりするケースで,

Webだと比較的楽なんですけどね。
上でも書きましたが、画面遷移を管理するフレームワークを作って、それを使わせるのがいいんじゃないかな。

# 安易な実装を許して、問題が起きたところだけ個別対処するってのも生産的じゃないし。

記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1828

　Re[6]: アプリケーション作成時に機能別にexeを分けていますか？

□投稿者/ Ognac -(2007/03/07(Wed) 11:10:30)

■No1823 (渋木宏明(ひどり) さん) に返信
>上でも書きましたが、画面遷移を管理するフレームワークを作って、それを使わせるのがいいんじゃないかな。
>安易な実装を許して、問題が起きたところだけ個別対処するってのも生産的じゃないし

そうですね。安易な実装を許さないために、防止策として制約を加えるという消極的対策と,フレームワーク等の仕組みを作る積極的対策がありますね。
消極的対策は絆創膏的な匂いがいますね。反省材料になりました。ありがとうございました。

記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1834

　Re[7]: アプリケーション作成時に機能別にexeを分けていますか？

□投稿者/ 渋木宏明(ひどり) -(2007/03/07(Wed) 11:43:02)

> そうですね。安易な実装を許さないために、防止策として制約を加えるという消極的対策と,フレームワーク等の仕組みを作る積極的対策がありますね。
> 消極的対策は絆創膏的な匂いがいますね。反省材料になりました。ありがとうございました。

小規模なモノなら消極策でもよろしいんじゃないでしょうか。
手当てに掛かるコストも小さくて済むでしょうし。

規模が大きくなればなるほど手当てや保守のコストがかさんでくるので、そういう時にこそ事前に下回りを整えてあげることでデスマーチ傾向が低まります。

記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1837

　Re[3]: アプリケーション作成時に機能別にexeを分けていますか？

□投稿者/ inat -(2007/03/07(Wed) 12:33:04)

■No1800 (Ognac さん) に返信
> 画面遷移の方向にもよりますが、この場合は、プロジェクトは　.exeプロジェクトであるべきでしょう。
> 案の定, Sub_AからSub_Bに移り,Sub_BからSub_Aに戻る必要がてぎた時に,相互参照でコンパイルエラーになってました。
デリゲートを使えば回避できると思いますが。。

記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1855

　Re[4]: アプリケーション作成時に機能別にexeを分けていますか？

□投稿者/ Ognac -(2007/03/07(Wed) 16:25:45)

■No1837 (inat さん) に返信
> ■No1800 (Ognac さん) に返信
>> 画面遷移の方向にもよりますが、この場合は、プロジェクトは　.exeプロジェクトであるべきでしょう。
>> 案の定, Sub_AからSub_Bに移り,Sub_BからSub_Aに戻る必要がてぎた時に,相互参照でコンパイルエラーになってました。
> デリゲートを使えば回避できると思いますが。。
仕組みを複雑にするのも考えものかと思いますが。どうでしょう。

記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1857

　Re[5]: アプリケーション作成時に機能別にexeを分けていますか？

□投稿者/ inat -(2007/03/07(Wed) 17:20:36)

■No1855 (Ognac さん) に返信
>>デリゲートを使えば回避できると思いますが。。
> 仕組みを複雑にするのも考えものかと思いますが。どうでしょう。
複雑ですか・・・複雑と言われてしまうとどうしようもないですが
私的にはexe分けよりかは良いと思いまして。
ちなみにVB.NETは使ったことがないのであまり詳しく言えませんが
私はC++/CLIを使っていてデリゲートの方が便利だなーと思いました。

記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1873

　Re[6]: アプリケーション作成時に機能別にexeを分けていますか？

□投稿者/ Ognac -(2007/03/07(Wed) 20:04:35)

■No1857 (inat さん) に返信
> ■No1855 (Ognac さん) に返信
> 複雑ですか・・・複雑と言われてしまうとどうしようもないですが

画面遷移は個々の画面に埋め込んだり,Delegateで処理すると遷移先が固定化されてしまい、保守性に欠けると思うのです。画面遷移クラスを作り、そちらにお任せするのが良いのではと考えます。

記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1902

　Re[7]: アプリケーション作成時に機能別にexeを分けていますか？

□投稿者/ Pandora -(2007/03/08(Thu) 15:19:08)

> 画面遷移クラスを作り、そちらにお任せするのが良いのではと考えます。

　そうであれば、なおさらexe単位で分ける必要はないのではないでしょうか？

　その画面遷移に責任を持つクラスが表示すべき画面を表示すれば良いのではないでしょうか？

　つまり、各画面は、自分の持分が終われば終了(クローズ)して、後は、画面遷移クラスに任せるというように

　すれば、複数のexeを作る必要はないと思いますが、どうでしょう。

記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1926

　Re[8]: アプリケーション作成時に機能別にexeを分けていますか？

□投稿者/ Ognac -(2007/03/08(Thu) 20:16:08)

■No1902 (Pandora さん) に返信
　>つまり、各画面は、自分の持分が終われば終了(クローズ)して、後は、画面遷移クラスに任せるというように
　>すれば、複数のexeを作る必要はないと思いますが、どうでしょう。
言葉足らずで御免なさい。
当初の発言の前提は, 画面遷移が考慮されずに,個々の画面に無造作に記述されて、その結果、循環参照状態に陥ったプロジェクトがあったものですから,予防策としての意味合いが強いです。
キチンと画面遷移を設計すれば, 全部DLLで、Okなんです。　が,サブシステム毎にクローズなEXEにしたメリットとして,単体で動作するので,違うチーム(会社)への振り分けとテストが行えることがあります。受け入れ側の怠慢でもあるのですが、...
exeとdllの差って何! COM時代の, Inprocess/OutProcess　の差ではないんですよね. 単独実行できるか否かの差でしかなければ,
dllでいいですね。発言の一部を撤回します。

記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

<< 0 >>

パスワード/

- Child Tree -