名前空間内、同じコンパイル済みアセンブリ内で型を収集するのが好きな傾向があります。これにより、物事を見つけやすくなり、参照を管理しやすくなります。
ただし、同じ名前空間がプロジェクトとアセンブリに分割されている例を見てきました(つまり、完全な名前空間にアクセスするには、複数のdllを参照する必要があります)。
誰かが私にあなたがこのようにコードを配置したいと思うかもしれないいくつかの正当な理由を教えてもらえますか?
ありがとう
名前空間内、同じコンパイル済みアセンブリ内で型を収集するのが好きな傾向があります。これにより、物事を見つけやすくなり、参照を管理しやすくなります。
ただし、同じ名前空間がプロジェクトとアセンブリに分割されている例を見てきました(つまり、完全な名前空間にアクセスするには、複数のdllを参照する必要があります)。
誰かが私にあなたがこのようにコードを配置したいと思うかもしれないいくつかの正当な理由を教えてもらえますか?
ありがとう
私は通常、他のアセンブリを必要とする機能を持つライブラリを作成しているときに、これを行っていることに気づきます。
たとえば、.NET データ型を SQL データ型に変換するコンバーターを作成しました。これらのほとんどは、標準のユーティリティ ライブラリに保持しています。ただし、のコンバーターにSystem.Drawing.PointF
は明らかに が必要System.Drawing
です。ユーティリティの名前空間を参照するすべてのプロジェクトで を強制的に参照するのではなくSystem.Drawing
、ライブラリのその部分を同じ名前空間の別のアセンブリにプルしました。変換する必要がある場合PointF
は、追加のアセンブリを参照し、他のすべてと同じ名前空間でコンバーターを見つけることができます。
私は実際にProgrammers.SEでこの質問をしました。