C＃名前空間とアセンブリのベストプラクティス
C＃：ソリューションを名前空間とアセンブリに分割する際のガイドライン、ベストプラクティスはありますか？ネームスペースは通常ネストされるべきであり、最下位レベルの基本クラスがトップレベルのネームスペースにありますか？一般に、1つのアセンブリに対して1つの名前空間が必要ですか？ 1つの名前空間に複数のアセンブリがある、または1つのアセンブリに複数の名前空間がある場合の落とし穴はありますか。複数のアセンブリまたは非常に大規模なアセンブリのコンパイル時/実行時のペナルティはありますか？
C＃：ソリューションを名前空間とアセンブリに分割する際のガイドライン、ベストプラクティスはありますか？
名前空間のガイドラインについては、フレームワークの設計ガイドラインをご覧ください。
アセンブリの場合：アセンブリは、定義上、.NETの自己記述型の出荷可能な機能の独立してバージョン付け可能な最小単位です。互いに独立して出荷またはバージョン管理する予定のソフトウェアの部分はありますか？次に、それらは異なるアセンブリにある必要があります。
ネームスペースは通常ネストされるべきであり、最下位レベルの基本クラスがトップレベルのネームスペースにありますか？
必ずしもそうではありません。
名前空間は、ユーザーがそれらの名前空間に含まれるタイプを簡単に見つけて理解できるように設計する必要があります。たぶん、あなたはユーザーに彼らの考えを尋ねるべきです。
一般に、1つのアセンブリに対して1つの名前空間が必要ですか？
必ずしもそうではありません。
1つの名前空間に複数のアセンブリがある、または1つのアセンブリに複数の名前空間があることの落とし穴はありますか。
特にありません。
複数のアセンブリまたは非常に大規模なアセンブリのコンパイル時/実行時のペナルティはありますか？
私が知っていることではありません。
Eric Lippertの発言をフォローアップするには：
アセンブリ名
アセンブリ内のほぼすべてのコードが単一の名前空間とサブ名前空間に存在し、名前空間にちなんで名前が付けられたアセンブリが伝統的です。
たとえば、ファイル名Contoso.PartnerPortal.Services.dllのアセンブリが指定された場合、アセンブリの短縮名は伝統的にContoso.PartnerPortal.Servicesであり、コードの大部分を期待しますContoso.PartnerPortal.Services名前空間（およびサブ名前空間）に存在する。
ただし、Contoso.PartnerPortal.Services名前空間のすべてのクラスが必ずしもContoso.PartnerPortal.Services.dllアセンブリに存在するわけではありません。 Contoso.PartnerPortal.dllアセンブリが存在する場合、Contoso.PartnerPortal.Services名前空間にもいくつかのクラスがある可能性があります。
これの一般的な用途の1つは、インターフェースでの使用です。インターフェイスがContoso.PartnerPortal.dllにある場合、そのアセンブリのコードはContoso.PartnerPortal.Services.dllを参照せずにインターフェイスを使用できます。 Contoso.PartnerPortal.Services.dll（インターフェイスを実装します）はおそらくContoso.PartnerPortal.dllを参照する必要があるため、これは重要であり、循環アセンブリ参照は回避するのが最善です。
アセンブリの数/サイズ
アセンブリが大きすぎると、コンパイルに必要以上に時間がかかる場合があります。これは、コンパイラが長い間インクリメンタルコンパイルをサポートしていないためです。したがって、モジュール全体を1つのユニットとしてコンパイルする必要があります。マルチモジュールアセンブリは頻繁に使用されないため、これは基本的に、アセンブリ全体を一度にコンパイルする必要があることを意味します。
大きなアセンブリをいくつかの小さなアセンブリに分割すると、変更されたアセンブリと参照するアセンブリのみが再コンパイルされます。これにより、時間を節約できます。
一方、1つのアプリケーションで600を超えるアセンブリを使用する（私は私の仕事でそのようなモンスターに取り組んでいます）には、それ自体に一連の問題があります。たとえば、ASP.netのシャドウコピー機能では、その多くのアセンブリでパフォーマンスの問題が発生しました（これは、ASP.netがaspxおよびascxファイルをコンパイルするときに作成される多数のアセンブリに加えて発生することに注意してください）。
ネームスペースは、ユーザーの便宜のために完全なクラス名を分割するための優れた方法です。したがって、名前空間を使用しても、コンパイル/実行時のペナルティやメリットはありません。
オブジェクトをアセンブリに分割すると、ランタイムとコンパイル時間が影響を受けます。また、非常に多数のアセンブリを使用しない場合は、高くなる可能性はほとんどありません。特定のケースの実際の測定なしでは、何が得られるか、または遅くなるかを予測することはできないことに注意してください。
論理的（つまり、サブシステムごと）/技術的（つまり、コンポーネントのバージョン管理のため）のニーズに基づいてプロジェクトをアセンブリに分割し、パフォーマンスが許容できるかどうかを確認する必要があります。そうでない場合は、アセンブリの数を原因とする前に、問題がどこにあるのかを把握する必要があります。