1

プロジェクト内のコード編成のベストプラクティスを理解しようとしています。私はインターネットで良い例を探しましたが、これまでのところ、参照する1つまたは複数のサポートクラスライブラリを備えたWebプロジェクト、または名前空間の規則に従うサブフォルダーを備えたWebプロジェクトの例を見てきました。

正しい答えがないと仮定すると、これは私が現在コード編成のために持っているものです：

MyProjectWeb

これは私のウェブサイトです。ここでクラスライブラリを参照しています。

MyProject.DLL

基本名前空間として、一般的に消費可能である必要があるファイルにこのDLLを使用しています。たとえば、私のプロジェクトのすべての列挙型を含む私のクラス「列挙型」はそこにあります。すべての例外処理のクラスMyProjectExceptionも同様です。

MyProject.IO.DLL

これは、ファイルのアップロードとダウンロードを処理する20個のファイルのグループです（これまでのところ）。

MyProject.Utilities.DLL

私の一般的なクラスとメソッドはすべて、1つの一般的に消費可能なDLLにまとめられています。各クラスは、「SqlHelper、AuthHelper、SerializationHelperなどの「XHelper」規則に従います...

MyProject.Web.DLL

このDLLをメインのクライアントインターフェイスとして使用しています。現在、ここにあるクラスファイルの大部分は次のとおりです。

1）プロパティ（学校、場所、アカウント、投稿など）2）承認関連のもの（カスタムメンバーシップ、カスタムロール、カスタムプロファイルプロバイダーなど）

私の質問は単純です-これは論理的に見えますか？

また、あるプロジェクトライブラリから次のプロジェクトライブラリにDLLを相互参照する必要をなくすにはどうすればよいですか？たとえば、MyProject.Web.DLLはMyProject.Utilities.DLLのコードを使用し、MyProject.Utilities.DLLはMyProject.DLLのコードを使用します。これは、プロパティをクリックして[依存関係]を選択することで解決しますか？それを試しましたが、選択したアセンブリの名前空間にアクセスしていないようです。各クラスライブラリに必要なすべてのアセンブリを参照する必要がありますか？

ご回答いただきありがとうございます。今しばらくお待ちいただきますようお願いいたします。

4

1 に答える 1

0

それはあなたの仮定から論理的に進むという点で論理的です。あなたがその質問をしているという事実は、あなたがそれが合理的だとは思わないかもしれないと私に信じさせます.

一般に、物事は技術的な境界ではなく、概念の境界に沿って分解する必要があります。MyProject.IO.DLL は、現在の設計にこの原則が表れている例です。すべての IO は論理的にまとめられるため、最終的には 1 つのバイナリになります。理にかなっています。

技術的なタイプ (enum、class など) に基づいて名前空間に分割することは、もう少し問題になります。

依存関係の問題は、1 つのクラスを多数のクラスに分割する場合と同じ問題であり、依存関係の反転という同じ手法を使用して解決されます。2 つのものが相互に依存する必要があるように見える場合は、最初の 2 つの間の契約を表す中間的なものを追加します。これは、抽象化、定数、メディエーターなどである可能性があります...必要なものは何でも、A が B に依存し、B が A に依存する代わりに、A と B が C に依存するようにします。

于 2010-04-16T00:40:29.747 に答える