モジュール性と関心の分離を強化するために、3 層の .NET アプリケーションを個別のプロジェクトに分割することを好みますが、コンピューターのパフォーマンスに問題がある (メモリと処理能力が不足している) ため、ビジュアル スタジオは遅く、作業が快適ではありません。 1 つのソリューションに多くのプロジェクトがあるため、すべてのレイヤーを 1 つのアセンブリに配置しますが、コードを使用して、各タイプがそれぞれのレイヤーにあるかのように設計します。1 つだけ知りたいのですが、これを試したことがあれば、お勧めするもの、しないもの、またはこれに関するアイデアはありますか?
私は議論を求めているわけではありません。この方法で深刻なリスクがあるかどうかを知りたいだけですか?
5 に答える
階層化が .NET やその他の厳密に型指定されたプラットフォームで有益である理由の 1 つは、プロジェクト/ライブラリ間に循環参照を (簡単に) 追加できないことです。これにより、少なくともパッケージ レベルでは、依存関係が有向非巡回グラフ(DAG) を形成することが保証されます。カップリングを減らす必要があるため、これは良いことです。
C#では、巡回グラフ (ClassA
参照ClassB
、参照ClassC
、参照)を形成するコードをコンパイルすることは完全に可能ClassA
です。したがって、すべてのコードを単一の Visual Studio C# プロジェクトに配置すると、階層化によって提供されるコンパイル時の保護の一部が削除されます。
ただし、代わりにプロジェクト全体をF#で記述すると、コンパイル時の保護が回復します。これは、F# コードにサイクルが含まれているとコンパイルされないためです (ただし、モジュール内でその規則に対する特定の例外を宣言することはできます... を参照してください)。相互再帰型のセクション)。
そのため、アプリケーション全体を C# で作成すると問題が発生する可能性が高くなりますが、F# で作成すれば問題はありません。
レイヤーを適切に分離するための規律を保持している限り、問題はありません。
私の経験では、ソース ファイルの数が同程度の場合、非常に大規模なプロジェクトは、複数のプロジェクト ソリューションと同じくらい悪いパフォーマンスを示しました。主に、これはディスクのパフォーマンス (私が持っていたマシンは 5400 rpm のディスクだったと思います) と大量のファイルの読み取りと書き込み (ディスク I/O アクティビティ) のブロックに関連しているようです。Visual Studio が行うことの多くはディスク (コンパイル、デバッグ、インテリセンスのファイル解析など) を扱っており、これが私の問題の原因の ようです。
ファイルを別々のプロジェクトに保存して、それぞれのソリューション ファイルを作成してみたくなります。