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

Ответ 1

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

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

Ниже приведены следующие правила:

• Имя проекта/сборки совпадает с корневым пространством имен, за исключением конца .dll
• Единственное исключение из вышеприведенного правила - проект с завершением .Core,.Core отключается.
• Папки равны пространствам имен
• Один тип файла (класс, структура, перечисление, делегат и т.д.) позволяет легко найти нужный файл

Ответ 2

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

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

Ответ 3

@lassevk: Я согласен с этими правилами и добавляю еще один.

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

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

и

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

Ответ 4

Нет.

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

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

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

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

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

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

Поиск файлов

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

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

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

Сопоставления имен

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

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

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

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

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

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 и браузер объектов

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

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

Ответ 5

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

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

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

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

Ответ 6

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