2 つの DLL を生成する VB.net プロジェクトを継承しました。1 つは Web アプリ用で、もう 1 つは「ビジネス レイヤー」用です。これは、より大きな Web サイトのサブアプリ用です。(VS2005 を使用)。
問題は、DLL と名前空間の構造に何か問題があることです。パフォーマンスへの影響があるかどうかを知りたいです。
メインの Web アプリは「Foo」で、Foo.dll を生成します。Foo.dll には名前空間 App.Foo が含まれており、すべてのページ、ユーザー コントロールなどのクラスが含まれています。
FooLib.dll を生成するプロジェクト「FooLib」もあります。FooLib.dll には、一連のクラス定義を含む App.Foo 名前空間も含まれています。App.Foo.Data、App.Foo.Logic など、他にもいくつかの名前空間があります。
これに問題はありますか？ランタイムはどのようにして複数の DLL からクラスを見つけますか?
これには何も問題はありません。考えられる唯一の問題は、1) "App.Foo.Something" を見ている開発者が、どのアセンブリを調べればよいかわからない可能性があることです。2) 両方で同じ名前が使用されている場合、アプリは (c# at at で) に対してコンパイルされます。少なくとも）あいまいな型名に関するエラーが発生します。
ランタイムに関しては、型はアセンブリと名前によって指定されます。名前空間は型名の一部です。したがって、ランタイムは型を見つけるのに問題はありません - どのアセンブリでそれを見つけるかについての情報をコンパイルすると、コンパイルされます。
プログラムがコンパイルされると、完全なタイプ名が「証拠」とともに含まれます。この証拠には、アセンブリの名前とバージョン情報が含まれます。そうしないと、クラスの 1.0 バージョンが必要なのか、1.1 バージョンが必要なのか、2.0 バージョンが必要なのかがわかりません。この同じシステムにより、異なるアセンブリの同じ名前空間で異なるクラスを見つけることができます。
パフォーマンスに関する限り、大きな影響はありません。有益な面としては、いくつかのものを異なる時間にロードできることを意味し、それは通常望ましい効果です。
名前空間は、見つけやすいように機能をパッケージ化するためのものです。アセンブリとは、効率的に読み込めるように機能をパッケージ化することです。時々それらは同じではありません。
いいえ、これには何も問題はありません。
私は多数のカスタム クラス ライブラリを使用しており、それらのほぼすべてが次の名前空間構造を持っていることを考慮してください。
.Web.UI.Controls.
System.Web.UI.Controls..
問題は、割り当てた数の DLL に適切な名前空間があることをコンパイラが認識することです (両方の DLL を検索します)。このようにまったく同じにすることをためらう唯一の理由は、開発者が混乱する可能性があるためです。もう 1 つの理由は、各名前空間にまったく同じ名前のクラスがある場合です。完全な名前の名前空間宣言で解決されるまで、コンパイラ エラーが発生します。
これが、名前空間をエイリアスできる理由の一部です。エイリアシングは両方の概念を解決します。その構造は次のようになります。
using Foo.App.Foo;
using FooLib = FooLib.App.Foo;
したがって、Foo.App.Foo と FooLib.App.Foo の両方に Bar クラスがある場合、アプリケーション バージョンにアクセスするには、次のようにします。
bar x = new bar();
使用するライブラリ バージョンの場合:
FooLib.bar x = new FooLib.bar();
いいえ、オーバーレイされた名前空間に問題はありません。多くの名前空間がオーバーレイされている .net フレームワーク自体を見てください。
名前空間は IL レベルには存在しません。ランタイムは、疑似完全修飾名、つまり、名前空間がプレフィックスとして付けられた型の名前からクラスを見つけます。
これを行うのに技術的な問題はないと思います。実際、.NET Framework 自体が複数の物理アセンブリで同じ名前空間を使用することがあります。
名前空間は .NET の世界では一級市民ではなく、残念です。