我继承了一个VB.net项目，该项目生成2个DLL：一个用于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中找到一个类？

解决方案

覆盖的名称空间没有错。看一下.net框架本身，其中覆盖了许多名称空间。

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

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

命名空间不是.NET世界的头等公民，对此我感到遗憾。

这没有任何问题，唯一的可能问题是：1)开发人员看到" App.Foo.Something"可能不知道在哪个程序集中查找2)如果两个应用程序都使用了相同的名称，那么应用程序将针对它们进行编译)会收到有关歧义类型名称的错误。

对于运行时，类型由程序集指定，名称空间仅是类型名的一部分。因此，在编译有关要在其中找到程序集的信息的编译信息时，运行时查找类型不会有问题。

编译程序时，将包含完整的类型名称以及"证据"。该证据包括程序集的名称和版本信息。否则，它不会知道我们是否要使用该类的1.0或者1.1或者2.0版本。使用同一系统，可以在不同程序集中的同一名称空间中找到不同的类。

就性能而言，没有太大的影响。从有利的方面来说，这意味着某些物料可以在不同的时间加载，这通常是所需的效果。

命名空间是关于打包功能的，它的查找方式很容易。程序集是关于有效装载方式的打包功能。有时它们是不一样的。

不，这没有错。

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

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