Если папки в растворе соответствует пространству имен?

голоса
98

Если папки в растворе соответствует пространству имен?

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

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

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

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

Внутри этого же проекта, еще один мошенник папку

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

Есть несколько случаев, как это, где папки сделаны для «организационного удобства».

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

Задан 07/08/2008 в 13:53
источник пользователем
На других языках...                            


7 ответов

голоса
59

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

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

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

  • Название проекта / сборка такая же, как корень пространства имен, за исключением .dll концовки
  • Единственное исключение из вышеуказанного правила является проектом с .Core окончания, то .Core отгоняют
  • Папки равно пространств имен
  • Один типа для каждого файла (класс, структуры, перечисление, делегат, и т.д.), позволяет легко найти нужный файл
Ответил 07/08/2008 в 13:58
источник пользователем

голоса
25

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

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

Ответил 07/08/2008 в 13:58
источник пользователем

голоса
24

Нет.

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

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

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

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

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

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

Поиск файлов

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

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

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

Имя столкновения

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

  • класс 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 и Object Browser

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

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

Ответил 25/03/2015 в 12:22
источник пользователем

голоса
21

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

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

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

а также

// ----- Foo.Bar.cs
partial class Foo
{
    class Bar
    {
        // Foo.Bar implementation here
    }
}
Ответил 11/09/2008 в 04:45
источник пользователем

голоса
4

Я бы сказал, что да.

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

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

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

Ответил 07/08/2008 в 13:57
источник пользователем

голоса
3

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

Ответил 07/08/2008 в 13:55
источник пользователем

голоса
0

Что стандарт?

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

В классе библиотека делать папки, как правило, соответствовать структуре пространства имен или это смешанный мешок?

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

Ответил 15/07/2018 в 07:00
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more