Каково влияние наличия пространств имен в нескольких библиотеках 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

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

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

.Web.UI.Controls.

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

Дело в том, что компилятор будет знать, что правильное пространство имен находится в таком количестве DLL, которое вы назначаете (он будет искать его в обеих DLL). Единственная причина, по которой я не решусь сделать их такими же, заключается в возможной путанице DEVELOPER . Другая причина в том, что в каждом пространстве имен есть класс с одинаковым именем, и это будет вызывать ошибку компилятора, пока она не будет решена с помощью полностью именованного объявления пространства имен.

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

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 2

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

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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