とにかくあなたが尋ねるものがあるとは思いません。オブジェクトをシリアル化するとどうなるかを考えると、データ ストリーム内でフィールドがどのように配置されるかという下位レベルの構造を提供するアセンブリが必要です。最初の 4 バイトが double などであることを示すには、インターフェイスのコードが必要です。
したがって、これを行う唯一の方法は、インターフェイスをすべてから参照できる新しい interfaces.dll に移動することです。このパターンは、EnterpriseLibrary を含む多くの例で繰り返されます。
しかし... あなたは古典的な間違いを犯しています。コードを非常に多くのプロジェクトに分割するのはなぜですか? プロジェクトは、時間の分離メカニズムを設計するのではなく、コードを実行時にパッケージ化するものと考える必要があります。非常に多くのアセンブリに分割することで、3 つのことを行います。
- コンパイラが他のアセンブリをフェッチする作業が増えるため、ビルド システムの速度が低下します。
- すべてのプロジェクトをロードしてプロジェクト間の参照を保持するのが難しくなるため、Visual Studio の速度が低下します。私はかつて、開くのに 15 分かかった 140 個のプロジェクトを含むソリューションに取り組んだことがあります (ただし、私はいつも朝のコーヒーを飲みました)。
- DotNet が別の 4k dll を検索する必要があるため、実行時のパフォーマンスが低下します (1 行のコードであっても、これは最小限です)。Fusion のログを確認するか、SysMon を使用して、この単純な操作にどれだけの作業が必要かを確認してください。
コードを最適化する方法に関するこの例のヒントを見てください。ソリューションがより複雑になるにつれて何が起こるかがわかります。
このように分割する代わりに、代わりに名前空間を使用します。分離は引き続き行われますが、非常に多くの参照を使用する代わりに、クラス内の using ステートメントによって制御できます。DSFinalProject 層にあるように設計されたクラスで DAL 参照を使用しているかどうかは簡単にわかります。プロジェクトの下にフォルダーを作成し、代わりにそこにクラスを追加するだけです。すべてのプロジェクトを取り除き、適切に階層化されたシステムを維持します。
ソリューションが拡大するにつれて、プロジェクトの導入を開始する前に少なくとも 2 つの実行可能ファイルが作成されるまで待ってから、実行時の影響を検討してください。常に 2 つのアセンブリをロードする場合は、それらを 1 つにマージします (最近、ilmerge を使用してサード パーティのライブラリでもマージするオープン ソース プロジェクトをいくつか見てきました)。