Пространства имен C # и передовая практика сборок

Question

C #: есть ли какие-либо руководящие принципы, лучшие практики, когда дело доходит до разделения решения на пространства имен и сборки? Должны ли пространства имен обычно быть вложенными с наиболее низкими уровнями и фундаментальными классами в пространстве имен верхнего уровня? Должно ли вообще быть одно пространство имен для одной сборки? Являются ли они любыми подводными камнями при наличии нескольких сборок в одном пространстве имен или нескольких пространств имен в одной сборке. Существуют ли какие-либо штрафы за время компиляции / выполнения для нескольких сборок или очень больших сборок?

Answer 1

C #: существуют ли какие-либо руководящие принципы, лучшие практики, когда дело доходит до разделения решения на пространства имен и сборки?

Инструкции для пространств имен см. В руководстве по проектированию структуры.

Для сборок: сборка по определению является наименьшей независимой версией для самостоятельного описания функциональности отправки в .NET. Существуют ли части вашего программного обеспечения, которые вы собираетесь поставлять или версии независимо друг от друга? Тогда они должны быть в разных сборках.

Должны ли пространства имен обычно быть вложенными с наиболее низкими уровнями и фундаментальными классами в пространстве имен верхнего уровня?

Не обязательно, нет.

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

Должно ли вообще быть одно пространство имен для одной сборки?

Не обязательно, нет.

Являются ли они любыми подводными камнями при наличии нескольких сборок в одном пространстве имен или нескольких пространств имен в одной сборке.

Не особо, нет.

Существуют ли какие-либо штрафы за время компиляции / выполнения для нескольких сборок или очень больших сборок?

Не то чтобы я знал.

Answer 2

В продолжение сказанного Эриком Липпертом:

Имена сборок

Традиционно почти весь код в сборке располагается в одном пространстве имен и подпространствах имен вместе со сборкой.назван в честь пространства имен.

Например, если бы мне дали сборку с именем файла Contoso.PartnerPortal.Services.dll , короткое имя сборки обычно будет Contoso.PartnerPortal.Services, иЯ ожидаю, что большая часть кода будет находиться в пространстве имен Contoso.PartnerPortal.Services (и под-пространствах имен).

Однако не все классы в пространстве имен Contoso.PartnerPortal.Services обязательно будут жить в Contoso.PartnerPortal.Services.Сборка длл.Если существует сборка Contoso.PartnerPortal.dll , она может также иметь некоторые классы в пространстве имен Contoso.PartnerPortal.Services.

Одним из распространенных примеров использования этого является интерфейс.Если интерфейсы находятся в Contoso.PartnerPortal.dll , тогда код в этой сборке может использовать интерфейс без ссылки на Contoso.PartnerPortal.Services.dll .Это важно, поскольку Contoso.PartnerPortal.Services.dll (который будет реализовывать интерфейсы), вероятно, потребуется ссылаться на Contoso.PartnerPortal.dll , а ссылки на циклические сборки лучше избегать.

Количество / размер сборок

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

Если вы разбиваете большую сборку на несколько более мелких, перекомпилируются только измененная сборка и те, на которые ссылается,Это экономит время.

С другой стороны, более 600 сборок в одном приложении (я работаю над таким монстром в своей повседневной работе) имеет свои проблемы.Например, функция теневого копирования ASP.net имела проблемы с производительностью при работе с таким количеством сборок (имейте в виду, что это в дополнение к большому количеству сборок, создаваемых, когда ASP.net компилирует файлы aspx и ascx).

Answer 3

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

Разделение объектов на сборки будет влиять на время выполнения и время компиляции, а также вряд ли будет высоким, если вы не используете слишком большое количество сборок. Обратите внимание, что невозможно предсказать, что вы получите, или медлительность без фактических измерений для вашего конкретного случая.

Вы должны разделить ваш проект на сборки на основе ваших логических (т.е. по подсистемам) / технических (то есть из-за управления версиями компонентов) и затем проверить, приемлема ли производительность. Если нет, вам нужно выяснить, где проблемы, прежде чем обвинять их в количестве сборок.