По материалам статьи Jonathan Goodyear: Standardize Your .NET Namespaces
Перевод Максима Зубова

Пространства имен могут помочь вам организовать исходники в ваших .NET проектах, но только если у вас есть четкий план.
Помните, как трудно было организовать исходные тексты COM объектов в вашей организации? У вас наверно было два имени верхнего уровня, с которыми вы и работали: имя проекта и имя класса. Обычно ваши идентификаторы выглядели примерно так:

XYZCompanyAccounting.Payroll

Очевидно, что такой подход далеко не самый лучший. Наверно было бы более удобно, если бы существовала возможность разделить пространство имен еще на несколько частей. Например, предыдущий идентификатор в .NET может быть представлен следующим образом:

XYZCompany.Accounting.Payroll

Не очень большая разница по сравнению с предыдущим объявлением, но она становится более очевидной, как только в ваших проектах появится более глубокая иерархия объектов.
На самом деле, .NET Framework предоставляет вам возможность создавать настолько глубокую иерархию пространства имен, насколько вам это необходимо. Однако, это может сделать многие вещи значительно не только проще для вашего понимания, но и наоборот, намного хуже. Аккуратное планирование и размышление над вложенностью пространств имен позволит вам пожинать хорошие плоды, такие как более удобная координация между отдельными командами разработчиков в вашей организации. Эта статья предлагает вам несколько полезных советов, как лучше организовать исходные тексты ваших .NET проектов, как с точки зрения пространства имен, так и с точки зрения использования Visual SourceSafe (VSS).

Структурируйте ваши пространства имен

Хорошо принять за правило, что бы каждое пространство имен, которое вы используете в каком-либо из модулей, начиналось с идентификатора вашей компании. Например: идентификатор в моем предыдущем примере начинался с "XYZCompany.". Следующая секция идентификатора вашего пространства имен зависит от соответствующей области, описываемой кодом. Если код описывает бизнес логику проекта, тогда следующая секция пространства имен должна содержать название вашего проекта (в данном случае "Accounting,"). Далее следует название подраздела вашего проекта (в нашем случае "Payroll"). Все это означает, что пространство имен в вашем проекте должно выглядеть так:

XYZCompany.Accounting.Payroll

Потом вы можете структурировать классы внутри пространства имен XYZCompany.Accounting.Payroll для своих конкретных задач. Для сегментации пространств имен бизнес логики на более мелкие сущности, вы можете разделить код вашего проекта на более специфичные части в VSS (более подробно об этом позже).
Веб проекты и веб службы на ASP.NET для именования пространств имен являются особым случаем. Хорошим стандартом в веб проектах на ASP.NET может быть такой: CompanyName.ProjectName.Website или CompanyName.ProjectName.WebServices для веб служб.
Следуя этому, пространство имен для веб сайта или веб службы бухгалтерских расчетов в компании XYZCompany могло бы быть:

XYZCompany.Accounting.Website
XYZCompany.Accounting.WebServices

Структура пространства имен, которую вы используете, может варьироваться, в зависимости от предметной области, которую описывает ваш код. Если ваш код будет использоваться в других проектах вашей организации, то не включайте в название пространства имен название своего проекта. Я также предлагаю вам не создавать своих собственных стандартов для названий пространств имен. Вместо этого следуйте лучше стандарту, который уже предложил Microsoft для .NET Framework. Например, если разработчики компании XYZCompany создали библиотеку классов, которую предполагается использовать для доступа к SQL Server в разных проектах, то соответствующее пространство имен следует назвать так:

XYZCompany.Data.SqlClient

В .NET Framework уже есть пространство имен System.Data.SqlClient.
Или, например, если разработчики компании XYZCompany создали библиотеку классов, которая инкапсулирует методы журналирования пользовательских событий, то название соответствующего пространства имен должно быть таким:

XYZCompany.Diagnostics

Всегда хорошо давать уникальные имена классам внутри одного пространства имен. Этим вы предотвращаете проблему с дублированием имен, когда необходимо использовать классы с одинаковыми именами, но из разных пространств имен. Важность создания своих пространств имен предложенным способом обусловлена несколькими причинами. Во-первых, выделяя в пространстве имен название своей компании, вы, тем самым, предотвращаемее возможные коллизии с продуктами третьих фирм, которые возможно будете использовать в будущем. Во вторых, адоптируя иерархию пространств имен, принятую в .NET Framework, вы облегчаете разработчикам поиск какого-либо класса во всей инфраструктуре компании, который им в данный момент нужен. Предложенный Microsoft стандарт возможно не идеален, но он позволяет разработчикам быстро и легко найти то, что им нужно, вместо того чтобы изучать разные документы и регламенты, в которых описывается структура репозитария вашей организации. В третьих, создавая иерархию пространств имен предложенным способом, вы потом сможете легко документировать его, создав похожую по стилю на MSDN документацию. Для этого можно будет использовать систему документирования, например NDoc.

Структурируйте ваши проекты

Теперь, когда вы привели в порядок названия ваших пространств имен, вам возможно будет интересно, как следует структурировать ваш проект в VSS. Я предлагаю два узла верхнего уровня в дереве VSS.

XYZ Enterprise .NET Class Library
XYZ Project .NET Class Library

Два узла верхнего уровня позволяют создать два различных вида документации (один для кода проекта и другой, для вашей компании). Под каждым узлом создайте узел с названием проекта (в нашем случае XYZCompany). Это будет вашим корнем пространства имен. В остальных узлах дерева продублируйте структуры ваших пространств имен, заменяя точки "." папками (см. рис.). Не забывайте давать полные имена файлам вашего проекта.
Пока я тут рассказываю о стандарте именования, позвольте дать вам совет о присвоении суффиксов именам классов, которые рекомендует Microsoft. Например, имена классов атрибутов должны оканчиваться словом "Attribute", а классы обработки исключений должны оканчиваться словом "Exception". Это по существу означает, что перед тем, как вы решите разработать новый класс, определите какого он будет типа и посмотрите библиотеку типов .NET Framework на предмет существования стандарта именования классов подобного типа. Если такой стандарт существует, следуйте ему. Структура пространства имен, о которой я рассказал, это просто предложение, как грамотней организовать ваши .NET исходники в компании. .NET только начинает использоваться в компаниях, поэтому сейчас самое подходящее время продумать структуры будущего хранилища исходных текстов и библиотек. Самая важная вещь, которую я пытался донести до вас с помощью этой статьи, это то, что нужно использовать стандарт именования пространств имен. Иначе случится так, что названия ваших пространств имен будут очень трудно восприниматься другими разработчиками, будут плохо структурированы, и вы получите то, с чем вероятно постоянно боретесь.

[В начало]