여러 DLL에 네임 스페이스가있는 영향은 무엇입니까?

Question

2 개의 DLL을 생성하는 VB.NET 프로젝트를 상속 받았습니다 : 하나는 웹 앱 용이고 다른 하나는 "비즈니스 계층"입니다. 이것은 더 큰 웹 사이트의 하위 앱을위한 것입니다. (VS2005 사용).

문제는 무언가가 DLL & 네임 스페이스 구조로 냄새가 나지 않으며 성능에 영향을 미치는지 알고 싶습니다.

기본 웹 앱은 "foo"이며 foo.dll을 생성합니다. foo.dll 모든 페이지, 사용자 컨트롤 등의 클래스가 포함 된 네임 스페이스 app.foo가 포함되어 있습니다.

Foolib.dll을 생성하는 프로젝트 "Foodib"도 있습니다. Foolib.dll에는 App.foo 네임 스페이스도 포함되어 있으며 수많은 클래스 정의가 포함되어 있습니다. app.foo.data, app.foo.logic 등과 같은 몇 가지 다른 네임 스페이스가 있습니다.

이것에 문제가 있습니까? 런타임은 여러 DLL에서 클래스를 어떻게 찾습니까?

Answer 1

프로그램이 컴파일되면 전체 유형 이름은 "증거"와 함께 포함됩니다. 이 증거에는 어셈블리 이름 및 버전 관리 정보가 포함됩니다. 그렇지 않으면 1.0 또는 1.1 또는 2.0 버전의 클래스를 원했는지 알 수 없습니다. 이 동일한 시스템을 사용하면 다른 어셈블리에서 동일한 네임 스페이스에서 다른 클래스를 찾을 수 있습니다.

성능이 진행되는 한 큰 영향은 없습니다. 유익한 측면에서 그것은 당신의 물건 중 일부가 다른 시간에로드 될 수 있으며 이는 일반적으로 원하는 효과입니다.

네임 스페이스는 쉽게 찾을 수있는 방식으로 포장 기능에 관한 것입니다. 어셈블리는로드하기에 효율적인 방식으로 포장 기능에 관한 것입니다. 때때로 그들은 동일하지 않습니다.

Answer 2

There's nothing wrong with this, the only possible issues may be that 1) developers seeing "App.Foo.Something" may not know which assembly to look in 2) if the same name is used in both, apps compiling against (in c# at least) will get errors about ambiguous type names.

As for the runtime, types are specified by assembly and name - the namespace is just part of the typename. So the runtime will have no issue finding the type - when you compile the information about what assembly to find it in is compiled in.

Answer 3

No, there's nothing wrong with this.

Consider, I use a number of custom class libraries, and nearly every one of them has the following namespace structure:

.Web.UI.Controls.

Which is similar (and suggested by MS as best practice) to System.Web.UI.Controls..

The thing is that the Compiler will know that there is the right namespace in as many DLLs as you assign (it will search for it across both DLLs). The only reason I'd hesitate at making them the exact same in this way is because of possible DEVELOPER confusion. The other reason is in case each namespace has a class named the exact same thing--and this will toss an compiler error until it is resolved with a fully named Namespace declaration.

Which is part of the reason why you can Alias namespaces. Aliasing will cure both concepts. The structure for it looks like this:

using Foo.App.Foo;
using FooLib = FooLib.App.Foo;

So, if you then have a Bar class in both Foo.App.Foo and FooLib.App.Foo, to access the application version you would use:

bar x = new bar();

For the Library version you'd use:

FooLib.bar x = new FooLib.bar();

Answer 4

No there is nothing wrong with overlayed namespaces. Take a look at the .net framework itself where many namespaces are overlayed.

Answer 5

Namespaces are not present at the IL level. The runtime find a class from a pseudo fully qualified name, that is, the name of the type prefixed by its namespace.

I don't think there is a technical problem to do that, in fact the .NET Framework itself sometimes uses same namespaces accross several physical assemblies.

Namespace are not first class citizen in the .NET world, and I regret that.