Должны ли папки в решении соответствовать пространству имен?

Должны ли папки в решении соответствовать пространству имен?

В одном из моих командных проектов у нас есть библиотека классов, которая имеет много подпапок в проекте.

Название проекта и пространство имен: MyCompany.Project.Section.

В этом проекте есть несколько папок, которые соответствуют разделу пространства имен:

  • Папка Vehiclesимеет классы в MyCompany.Project.Section.Vehiclesпространстве имен
  • Папка Clothingимеет классы в MyCompany.Project.Section.Clothingпространстве имен
  • и т.п.

Внутри этого же проекта находится еще одна мошенническая папка

  • Папка BusinessObjectsимеет классы в MyCompany.Project.Sectionпространстве имен

В некоторых случаях подобные папки создаются для «организационного удобства».

Мой вопрос: какой стандарт? В библиотеках классов папки обычно соответствуют структуре пространства имен или это смешанный пакет?

7.08.2008 12:53:19
Примечание: ReSharper будет жаловаться, если пространства имен не соответствуют иерархии папок.
Fred 13.03.2016 20:00:35
7 ОТВЕТОВ
РЕШЕНИЕ

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

Классы будет легче найти, и это само по себе должно быть достаточно хорошим поводом.

Правила, которым мы следуем:

  • Имя проекта / сборки совпадает с корневым пространством имен, за исключением окончания .dll
  • Единственным исключением из вышеприведенного правила является проект с окончанием .Core, где .Core удаляется
  • Папки равны пространствам имен
  • Один тип на файл (класс, структура, перечисление, делегат и т. Д.) Позволяет легко найти нужный файл
73
1.08.2010 19:08:06
+1 за «Единственное исключение из вышеприведенного правила - это проект с окончанием .Core, а .Core удаляется» один. У меня есть MyProject.Core.dllсборка, и все занятия начинаются с MyProject.Core. Снятие .Coreсуффикса имеет гораздо больше смысла.
Luiz Damim 24.04.2013 23:29:54
Еще одно исключение, которое я мог бы добавить, это исключения. К исключениям уже добавляется суффикс «Исключение», поэтому дополнительное пространство имен является избыточным. Это также может привести к путанице в части пространства имен со словом Exception (может привести к путанице в System.Exception). Тем не менее, организация их в папки весьма полезна.
phillipwei 13.01.2015 23:14:18
У меня есть MyProject в качестве имени Porject и папка MyProject.Views для хранения файлов views.cs, но когда я упомянул пространство имен MyProject.Views в моем MainWindow.xaml, я получил сообщение об ошибке «Views», не существует в пространстве имен «MyProject». Почему ?
MindRoasterMir 7.01.2019 22:55:41

Да, они должны, только приводит к путанице в противном случае.

4
7.08.2008 13:01:19

Я бы сказал, да.

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

Во-вторых, VS генерирует новые классы, которые вы создаете в папках с тем же пространством имен, что и у его родительской структуры папок. Если вы решите плыть против этого, это будет просто еще одна сантехническая работа, которую нужно выполнять ежедневно при добавлении новых файлов.

Конечно, само собой разумеется, что нужно быть осторожным относительно глубины иерархии xis folder / namespace.

5
7.08.2008 12:57:13

Я думаю, что стандартом в .NET является попытка сделать это, когда это возможно, но не создавать излишне глубокие структуры, просто придерживаясь этого в качестве жесткого правила. Ни один из моих проектов не следует правилу пространства имен == 100% времени, иногда его просто чище / лучше вырваться из таких правил.

В Java у вас нет выбора. Я бы назвал это классическим случаем того, что работает в теории, а не на практике.

31
7.08.2008 12:58:13
Я бы сказал: «Делай это, когда ты действительно хочешь, чтобы что-то было в собственном пространстве имен». Это должно быть осознанное решение. Если ваши проекты должным образом изолированы, это должно быть одно пространство имен на проект. Если ваш класс находится в пространстве имен, он должен находиться в папке с этим пространством имен ИЛИ в подпапке, которая по крайней мере столь же специфична, как и пространство имен. Такой класс, как Car.Ford.Fusion (если Car.Ford является вашим единственным пространством имен), должен находиться в папке, например, «Car / Ford» или «Глубже», например «Car / Ford / Sedans», так, чтобы эта папка была как минимум такой же специфичной, как и пространство имен. Только не помещайте это в Автомобиль / Несвязанный / Форд; это сбивает с толку
Triynko 2.05.2017 18:08:24

@lassevk: Я согласен с этими правилами и хочу добавить еще одно.

Когда у меня есть вложенные классы, я все равно делю их по одному на файл. Как это:

// ----- Foo.cs
partial class Foo
{
    // Foo implementation here
}

и

// ----- Foo.Bar.cs
partial class Foo
{
    class Bar
    {
        // Foo.Bar implementation here
    }
}
23
11.09.2008 03:45:56

Нет.

Я испробовал оба метода на малых и больших проектах, как с одним (мной), так и с командой разработчиков.

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

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

Возьмите это предупреждение FxCop, например:

CA1020: Избегайте пространств имен с несколькими типами
причин: пространство имен, отличное от глобального пространства имен, содержит менее пяти типов https://msdn.microsoft.com/en-gb/library/ms182130.aspx

Это предупреждение поощряет сброс новых файлов в общую папку Project.General или даже в корневой каталог проекта до тех пор, пока у вас не будет четырех похожих классов, чтобы оправдать создание новой папки. Это когда-нибудь случится?

Поиск файлов

Принятый ответ гласит: «Классы будут легче найти, и это само по себе должно быть достаточно хорошим поводом».

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

В любом случае, хотя вы не можете определить, в какой папке находится файл класса, из пространства имен, вы можете найти его с помощью Перейти к определению или окна обозревателя решения поиска в Visual Studio. Кроме того, это не очень большая проблема, на мой взгляд. Я не трачу даже 0,1% своего времени на разработку файла, чтобы оправдать его оптимизацию.

Конфликты имен

Конечно, создание нескольких пространств имен позволяет проекту иметь два класса с одинаковыми именами. Но разве это хорошо? Может быть, проще просто запретить это сделать возможным? Разрешение двух классов с одинаковым именем создает более сложную ситуацию, когда в 90% случаев все работает определенным образом, а затем внезапно обнаруживается, что у вас есть особый случай. Допустим, у вас есть два класса Rectangle, определенных в отдельных пространствах имен:

  • Класс Project1.Image.Rectangle
  • Класс Project1.Window.Rectangle

Возможно столкнуться с проблемой, что исходный файл должен включать оба пространства имен. Теперь вам нужно выписать полное пространство имен в этом файле:

var rectangle = new Project1.Window.Rectangle();

Или возиться с каким-нибудь неприятным оператором using:

using Rectangle = Project1.Window.Rectangle;

С одним пространством имен в вашем проекте вы вынуждены придумывать разные, и я бы сказал, более описательные имена, подобные этим:

  • класс Project1.ImageRectangle
  • Класс Project1.WindowRectangle

И использование везде одинаково, вам не нужно иметь дело с особым случаем, когда файл использует оба типа.

используя заявления

using Project1.General;  
using Project1.Image;  
using Project1.Window;  
using Project1.Window.Controls;  
using Project1.Shapes;  
using Project1.Input;  
using Project1.Data;  

против

using Project1;

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

Изменение структуры папок проекта

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

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

Visual Studio автоматически сопоставляет пространство имен нового файла с папкой проекта, в которой он создан

К сожалению, но я считаю, что хлопоты по исправлению пространства имен меньше, чем хлопоты с ними. Также я привык копировать существующий файл вместо того, чтобы использовать Add-> New.

Intellisense и Object Browser

На мой взгляд, самое большое преимущество использования нескольких пространств имен в больших проектах - это дополнительная организация при просмотре классов в любом инструменте, который отображает классы в иерархии пространств имен. Даже документация. Очевидно, что наличие только одного пространства имен в проекте приводит к тому, что все классы отображаются в одном списке, а не разбиваются на категории. Однако лично я никогда не был озадачен или задержан из-за отсутствия этого, поэтому я не считаю это достаточно большим преимуществом для оправдания нескольких пространств имен.

Хотя, если бы я писал большую публичную библиотеку классов, я бы, вероятно, использовал несколько пространств имен в проекте, чтобы сборка выглядела аккуратно в инструментах и ​​документации.

46
14.04.2015 15:12:40
Честно говоря, это одно из самых кошмарных решений, которые я слышал. Если вы работаете над небольшими проектами Hello World, этот совет работает, но представьте, что у вас есть более 1000 файлов .cs. Это вызвало бы так много проблем, что я не знаю с чего начать.
BentOnCoding 7.04.2015 20:56:41
msgstr "но представьте, что у вас есть более 1000 файлов .cs". Я работал над проектами такого размера с одним пространством имен. Все нормально. Как вы думаете, какое бедствие произойдет?
Weyland Yutani 14.04.2015 15:08:14
+1 за размышления. Я не думаю, что я готов сократить свои пространства имен до одного для каждого проекта, но после работы над большой платформой я изучаю возможность уменьшения количества пространств имен, чтобы уменьшить количество используемых операторов и помочь в обнаружении методов расширения. Я думаю, что этот ответ дает хорошую пищу для размышлений. Спасибо.
Lee Gunn 26.04.2015 16:08:23
@WeylandYutani я знаю, что опаздываю, но я должен отметить, что это предложение: you can find it by using Go To Definition or the search solution explorer box in Visual Studioне всегда верно. Попробуйте это с большим количеством наследования и интерфейсов ... удачи в поиске правильного файла.
Emmanuel M. 5.08.2016 09:55:38
Это один из лучших советов, которые я видел. Пространства имен предназначены только для разрешения конфликтов, а не для организации классов. Используйте пространства имен только в тех случаях, когда их целесообразно использовать, например там, где вы ожидаете конфликт имен с другими проектами, которые могут использовать ваш проект, что позволяет включать определенные пространства имен или исключать их с помощью операторов. Ужасно иметь проект с 3 или 4 или более часто используемыми пространствами имен, потому что это всегда приводит к смешному количеству операторов использования, которые вам нужно добавлять, добавлять, добавлять и добавлять. Разбейте свои проекты на части.
Triynko 2.05.2017 17:58:46

Какой стандарт?

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

В библиотеках классов папки обычно соответствуют структуре пространства имен или это смешанный пакет?

Да, в большинстве библиотек классов папки соответствуют пространству имен для удобства организации.

2
15.07.2018 07:00:30