在多个DLL中使用命名空间有什么影响？

Question

我继承了一个生成2个DLLS的VB.net项目：一个用于Web应用程序，另一个用于“业务层”。这是针对较大网站的子应用程序。 （使用VS2005）。

问题在于DLL和＆amp;命名空间结构，我想知道是否有任何性能影响。

主网络应用程序是“Foo”，并生成Foo.dll。 Foo.dll包含名称空间App.Foo，其中包含所有页面，用户控件等的类。

还有一个项目“FooLib”生成FooLib.dll。 FooLib.dll还包含一个App.Foo命名空间，其中包含许多类定义。还有一些其他命名空间，如App.Foo.Data，App.Foo.Logic等。

这有什么问题吗？运行时如何在多个DLL中找到一个类？

Answer 1

编译程序时，包含完整类型名称和“证据”。此证据包括程序集的名称和版本信息。否则，它不知道你是否想要1.0或1.1或2.0版本的类。这个系统允许它在不同的程序集中的同一名称空间中查找不同的类。

就性能而言，没有太大的影响。在有益的方面，它意味着你的一些东西可以在不同的时间加载，这通常是期望的效果。

命名空间以一种易于查找的方式提供打包功能。装配是以有效加载的方式进行封装功能。有时它们不一样。

Answer 2

这没有任何问题，唯一可能的问题可能是1）开发人员看到“App.Foo.Something”可能不知道要查看哪个程序集2）如果两者中使用相同的名称，编译的应用程序（至少在c＃中）将获得有关模糊类型名称的错误。

对于运行时，类型由程序集和名称指定 - 命名空间只是typename的一部分。因此运行时没有问题找到类型 - 当您编译有关要在其中编译的程序集的信息时编译。

Answer 3

不，这没什么不对。

考虑一下，我使用了许多自定义类库，并且几乎每一个都有以下命名空间结构：

  

.Web.UI.Controls。

与System.Web.UI.Controls类似（并由MS作为最佳实践建议）..

问题是编译器会知道在你分配的DLL中有正确的命名空间（它将在两个DLL中搜索它）。我不愿意以这种方式使它们完全相同的唯一原因是因为可能存在 DEVELOPER 混淆。另一个原因是，如果每个命名空间都有一个名为完全相同的类 - 这将抛出编译器错误，直到用完全命名的命名空间声明解析它。

这是Alias命名空间的部分原因。别名将治愈这两个概念。它的结构如下所示：

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();

Answer 4

重叠名称空间没有任何问题。看一下.net框架本身，其中覆盖了许多名称空间。

Answer 5

IL级别不存在命名空间。运行时从伪完全限定名称中查找一个类，即名称前缀为其名称空间的类型。

我认为没有技术问题，实际上.NET Framework本身有时会在几个物理程序集中使用相同的命名空间。

命名空间在.NET世界中不是一等公民，我很遗憾。