C# Namespaces and Assemblies Best Practice
C#: есть ли какие-либо рекомендации, лучшие практики, когда дело доходит до разделения решения на пространства имен и сборки? Должны ли пространства имен обычно быть вложенными, с наиболее низкоуровневыми и фундаментальными классами в пространстве имен верхнего уровня? Должно ли быть одно пространство имен для одной сборки? Существуют ли какие-либо недостатки при использовании нескольких сборок в одном пространстве имен или нескольких пространств имен в одной сборке. Есть ли какие-либо штрафы за время компиляции или выполнения для нескольких сборок или очень больших сборок?
1 ответ
Чтобы продолжить то, что сказал Эрик Липперт:
Имена сборок
Традиционно почти весь код в сборке располагается в одном пространстве имен и подпространствах имен, вместе со сборкой. назван в честь пространства имен.
Например, если бы мне дали сборку с именем файла Contoso.PartnerPortal.Services.dll , короткое имя сборки традиционно было бы Contoso.PartnerPortal.Services, и я ожидал бы большую часть кода жить в пространстве имен Contoso.PartnerPortal.Services (и подпространствах имен).
Однако не все классы в пространстве имен Contoso.PartnerPortal.Services обязательно будут жить в сборке Contoso.PartnerPortal.Services.dll. Если существует сборка 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).