汎用機システムでは1画面で一つのプログラム(1個のexe_File)というのが当然でした。(複数も可能ですが)
(*)汎用機Onlineでは中央制御なので、そうするのが当然且つ楽な面もあります。Webアプリは仕組み上,画面単位なので対象外にします。
3階層やMVCの手法が脚光をあびてますが, 汎用機の画面は画面毎にCloseした設計になるので, 意識しなくても, 3階層に近づいた設計になります。
WindowsForm の世界では, 1システムを一つの プロジェクトでで構築する事があるようです。
?? (以下の展開は反対意見も多いのですが、経験値としての考えです。)
１つのシステムを 、(複数のサブシステムを含めて) 1つのプロジェクトで構築して,巨大なEXEでシステム展開するのは如何なものでしょう?
最低でも一つのサブシステムを一つのプロジェクト(DLL)にして欲しいところです。
MVCや三階層がしっかり考慮されてれば, 1つのプロジェクトに多く画面を詰め込んでも,見通しがいいですが,
?皮肉な事に、考慮されるシステムでは複数のプロジェクトにで構築してくれます。
それを意識しないで、1つのExeに多くの画面を詰め込むと、開発時は楽かも知れませんが,後の保守工数で面倒な事になりがちです。
(もちろん,描画ソフトやEditorなど,高機能とパフォーマンスの都合で1プロジェクトに詰め込む必要がある場合もあります。ここでは一般的な業務アプリを想定しています。)
プログラムのスパゲッティ化は無作法で顰蹙を買うようになったのは喜ばしいことです。
しかし,サブシステム同士の結合や、画面遷移が複雑になりスパゲッティになっているのを見かけます。
プログラムのスパゲティよりもこっちの方が難儀なモノです。この部分の文書化は杜撰な事が多く、システム改造の時にデスマに落ち込むことがあります。
プログラムソースは行儀が良くても、個々のサブシステム間の関係が混乱すると動かないシステムになります。
120画面からなるシステムが1プロジェクトで作られていました。
?メニュー指示で各画面に遷移するのですが,なんとexeのLoad時に 120画面全て,インスタンス化していました。
?次の画面への展開で都度インスタンス化するのは面倒なので,そのようにしたのかもしれません, これは反則でしょ(?)
?入金処理のために, exeを起動して,入金処理後終了といった使用方法が多いのですが、その際は, 5画面しか使わないのです。
?個々のプログラムソースは綺麗で行儀よく作られてますが, クラス連携(画面展開)がこれでは如何なものでしょう。
綺麗で動かないプログラム .VS. 汚くても動くプログラム の論争がありますが。
このシステムは綺麗で動くシステムに分類されていたみたいです。蓋を開けてびっくりした次第です。
コードレビューでここまで見抜くのは厳しいかも知れません。システムの検証は難しいものです。
コネクション/ Transaction / オブジェクト(画面含む) は 使う時に作成し,使い終わったら速やかに,お引取り願うような作りが肝要です。