我继承了一个生成2个DLLS的VB.net项目:一个用于Web应用程序,另一个用于“业务层”。这是针对较大网站的子应用程序。 (使用VS2005)。
问题在于DLL和&命名空间结构,我想知道是否有任何性能影响。
主要的网络应用程序是“Foo”,并生成Foo.dll。 Foo.dll包含名称空间App.Foo,其中包含所有页面,用户控件等的类。
还有一个生成FooLib.dll的项目“FooLib”。 FooLib.dll还包含一个App.Foo命名空间,其中包含许多类定义。还有一些其他命名空间,如App.Foo.Data,App.Foo.Logic等。
这有什么问题吗?运行时如何在多个DLL中找到一个类?
答案 0 :(得分:1)
这没有任何问题,唯一可能的问题可能是1)开发人员看到“App.Foo.Something”可能不知道要查看哪个程序集2)如果在两者中使用相同的名称,则编译的应用程序(在c#中至少会得到关于模糊类型名称的错误。
对于运行时,类型由程序集和名称指定 - 命名空间只是typename的一部分。因此运行时没有问题找到类型 - 当您编译有关要在其中编译的程序集的信息时编译。
答案 1 :(得分:1)
编译程序时,将包含完整类型名称和“证据”。此证据包括程序集的名称和版本信息。否则,它不知道你是否想要1.0或1.1或2.0版本的类。这个系统允许它在不同的程序集中的同一名称空间中查找不同的类。
就性能而言,没有太大的影响。在有益的方面,它意味着你的一些东西可以在不同的时间加载,这通常是期望的效果。
命名空间以一种易于查找的方式提供打包功能。装配是以有效加载的方式进行封装功能。有时它们不一样。
答案 2 :(得分:1)
不,这没什么不对。
考虑一下,我使用了许多自定义类库,并且几乎每一个都有以下命名空间结构:
.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();
答案 3 :(得分:0)
重叠名称空间没有任何问题。看一下.net框架本身,其中覆盖了许多名称空间。
答案 4 :(得分:0)
IL级别不存在命名空间。运行时从伪完全限定名称中查找一个类,即名称前缀为其名称空间的类型。
我认为没有技术问题,实际上.NET Framework本身有时会在几个物理程序集中使用相同的命名空间。
命名空间在.NET世界中不是一等公民,我很遗憾。