Каково влияние наличия пространств имен в нескольких DLL?

Question

Я унаследовал проект VB.net, который генерирует 2 библиотеки DLLS:один для веб-приложения, а другой для «бизнес-уровня».Это дополнительное приложение более крупного веб-сайта.(Использование VS2005).

Проблема в том, что что-то не так со структурой DLL и пространства имен, и я хотел бы знать, есть ли какие-либо последствия для производительности.

Основное веб-приложение — «Foo» и генерирует Foo.dll.Foo.dll содержит пространство имен App.Foo, которое содержит классы для всех страниц, пользовательских элементов управления и т. д.

Также существует проект FooLib, который генерирует FooLib.dll.FooLib.dll также содержит пространство имен App.Foo, содержащее множество определений классов.Существует несколько других пространств имен, таких как App.Foo.Data, App.Foo.Logic и т. д.

Есть ли в этом что-то не так?Как среда выполнения находит класс в нескольких библиотеках DLL?

Answer 1

Когда ваша программа компилируется, полное имя типа включается вместе с «evidence».Это свидетельство включает имя сборки и информацию о версии.В противном случае он не будет знать, нужна ли вам версия класса 1.0, 1.1 или 2.0.Эта же система позволяет находить разные классы в одном и том же пространстве имен в разных сборках.

Что касается производительности, то особого эффекта нет.С положительной стороны это означает, что некоторые ваши данные могут загружаться в разное время, и обычно это и есть желаемый эффект.

Пространства имен предназначены для упаковки функциональности таким образом, чтобы ее было легко найти.Сборки предназначены для упаковки функциональных возможностей таким образом, чтобы их можно было эффективно загружать.Иногда они не одинаковы.

Answer 2

В этом нет ничего плохого, единственные возможные проблемы могут заключаться в том, что 1) разработчики, видящие «App.Foo.Something», могут не знать, в какой сборке искать 2) если в обоих используется одно и то же имя, приложения компилируются (в С# на минимум) будут получать ошибки о неоднозначных именах типов.

Что касается среды выполнения, типы указываются по сборке и имени — пространство имен является лишь частью имени типа.Таким образом, у среды выполнения не возникнет проблем с поиском типа - при компиляции компилируется информация о том, в какой сборке его найти.

Answer 3

Нет, в этом нет ничего плохого.

Учтите, я использую несколько пользовательских библиотек классов, и почти каждая из них имеет следующую структуру пространства имен:

.Web.UI.Controls.

Это похоже (и предложено MS как лучшая практика) на System.Web.UI.Controls..

Дело в том, что компилятор будет знать, что правильное пространство имен есть во всех назначенных вами DLL (он будет искать его в обеих DLL).Единственная причина, по которой я бы колебался делать их абсолютно одинаковыми, — это возможность РАЗРАБОТЧИК путаница.Другая причина заключается в том, что каждое пространство имен имеет класс с одним и тем же именем - и это будет вызывать ошибку компилятора, пока она не будет устранена с помощью объявления пространства имен с полным именем.

Это одна из причин, по которой вы можете использовать псевдонимы пространств имен.Псевдонимы исправят обе концепции.Структура для него выглядит следующим образом:

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

Итак, если у вас есть класс Bar как в Foo.App.Foo, так и в FooLib.App.Foo, для доступа к версии приложения вы должны использовать:

bar x = new bar();

Для версии библиотеки вы должны использовать:

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

Answer 4

Нет, в наложенных пространствах имен нет ничего плохого.Взгляните на саму платформу .net, в которой наложено множество пространств имен.

Answer 5

Пространства имен отсутствуют на уровне IL.Среда выполнения находит класс по псевдополному имени, то есть по имени типа, перед которым стоит его пространство имен.

Я не думаю, что это является технической проблемой, на самом деле сама .NET Framework иногда использует одни и те же пространства имен в нескольких физических сборках.

Namespace не является первоклассным гражданином в мире .NET, и я сожалею об этом.