VB.netの設計

質問

JavaのSE経験5年、VBは開発3ヶ月未満のSEです。
ある汎用業務アプリを旧アプリ（VB6）から新アプリ（VB.net）に移行するプロジェクトに携わっています。

旧アプリは、ひとつのメニューExeから、各機能（画面）EXEをコマンドラインから呼び出す作りです。
例えば、こんな感じです。
　携帯電話
　　→携帯電話メニュー画面.exe
　　→アドレス帳検索画面.exe
　　→アドレス帳登録画面,exe
　　→アドレス帳削除画面.exe
　　→Eメール履歴画面,exe
　　→Eメール送信画面.exe
　　→Eメール受信画面,exe

画面ごとにプロジェクトファイルがあり、出来上がりの納品の際は、Exeファイルが数十個出来るようなアプリケーションになっています。
しかし、コマンドラインでexeを実行する手法と、画面ごとにexeが出来る事に違和感を感じますし、
直接メニューを通さずに呼ばれることがない物にexeと言う拡張子がつく事にも違和感を感じます。
作りとして、EXEが沢山あるソリューションは正しいのでしょうか
正しくないとして、どうあるのが正しいのでしょうか

よろしくお願いいたします。

回答No.4

equinox2 · ベストアンサー

VB.NETでEXEが数百本＋DLLが100本以上必要なシステム開発の
経験がありますが、EXEを分けること自体は正しくないとは言えない
と思います。
＃メニューが頻繁に変更されるなどの特殊な要件がなければ
＃コマンドライン経由の起動はしないと思いますが・・

VB6からVB.NETで一番気にしなければならないのは、EXE->EXE起動が
遅くなることでしょうか。
これが許容できれば分けておいたほうが開発（テスト）やメンテナンス
には有効でしょう。

回答No.5

don_go

ソフトの開発方法においては、様々な手法が有り、
何が正しくて何が正しくないかに対する解答はあり
ません。
VBやJava以前の言語の仕様や当時のPCの性能の制限
により、さらに異なった開発方法というのは存在して
いましたし、将来作られる事になる言語に用いられる
手法から見た時、現在の手法が違和感を持って見られる
事が無いとは断言できません。

敢えて言うならば、手法に拘った挙句に、納期と予算
を大きく越える様な事にしてしまうのは、正しいとは
言い難いと思います。
＃既存システムの移行作業の場合、予算が大きく取れ
＃ない場合が多いので、どこまで妥協するかの判断が
＃難しくなります。

回答No.3

noname#259269

EXEを複数起動する場合、仮に一つが落ちてもシステム毎落ちる事は避けることができますよね。
そういった点も考慮してみてください。
要するに色々な視点でメリットデメリットを考える必要があります。

回答No.2

うぃず（@Wizard_Zero）

> 作りとして、EXEが沢山あるソリューションは正しいのでしょうか

一概に「間違っている」とは言えません。

特にVB6.0のExeは１プロセス＝１スレッドなので、マルチスレッド化のためにExeを分けるという手法は取られていると思います。この場合、マルチスレッドは.NETでサポートされているので、Exeを分ける必要はありません。

分散開発のためにExeが分けられており、今後もチームで開発を続けるのであれば、Exeをまとめるのは難しいかもしれませんね。Exeを分散したままで気になることといえば、.NETのExeでは実行時にネイティブコードへの変換が入る分だけオーバーヘッドが大きくなることでしょうか。

私だったら、複数のExeは実行時のトラブルを招きやすそうなので、メインExe＋クラスライブラリという構成を取ります。名前空間とインターフェイスさえ決めておけば、個々のプロジェクトは分散して開発できますし、完成したらソースファイルを一箇所にまとめてビルドすることでExe単体にもできます。まぁ、時と場合にもよりますが・・・。

回答No.1

rivoisu

あまりかっこよくないけど、
「作りやすい」「単体でテストができる」ということでそうなっているのではないですか。

正しいかどうかというのは良くわかりません。