Следует ли мне перестать бороться с соглашением об именах пространств имен Visual Studio по умолчанию?

Я работаю над проектом MVVM, поэтому у меня есть папки в моем проекте, такие как Models, ViewModels, Windows и т. Д. Каждый раз, когда я создаю новый класс, Visual Studio автоматически добавляет имя папки в обозначение пространства имен, а не просто сохраняет проект. level пространство имен. Таким образом, добавление нового класса в папку ViewModels приведет к пространству имен MyProject.ViewModels вместо просто MyProject.

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

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

Вопросы:

  • Почему существует общепринятое соглашение, согласно которому имена пространств имен отражают структуру папок?
  • Вы соблюдаете это соглашение? Почему?

visual-studio c# namespaces naming-conventions
person devuxer    schedule 17.08.2009    source источник

Ответы (10)


arrow_upward
46
arrow_downward

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

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

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

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

person Jordan Parmer    schedule 17.08.2009
comment
Я считаю, что папки должны соответствовать пространству имен. Вы должны работать с этим, чтобы сделать его полезным. На самом деле, я лично хотел бы, чтобы папки создавались автоматически на основе пространства имен ваших классов. - person Didier A.; 19.02.2014
comment
Я считаю, что дочерние папки корневого уровня соответствуют пространствам имен, но иногда я хочу использовать папки, чтобы уменьшить размер проводника решений и использовать то же корневое пространство имен. Например. скажем, я работаю над масштабным проектом MVC, и у меня есть куча pocos для представления всех данных. Итак, у меня есть папка Entities, и дать им всем это пространство имен - это круто. Но я не хочу, чтобы в корневой папке было 350 поко. Я не хочу помещать их в пространство имен, потому что мне не нужны 20 операторов using, чтобы использовать их кучу в одном файле. Все в Entities хорошо, все в корневой папке плохо .. - person Ryan Mann; 28.09.2014
comment
Я думаю, что стоит отметить, что существует сильная критика этого типа послойного стиля, и многие будут утверждать, что предпочтение отдается отдельным функциям (например, вместо Views/AccountView | Controllers/AccountController вы делаете Account/AccountView | Account/AccountController. Идея состоит в том, чтобы иметь более модульную архитектуру и избежать проблем, связанных с наличием большого количества классов в представлениях и большого количества классов в моделях. Я согласен с тем, что папки должны соответствовать пространствам имен. Почему еще вы даже используете папки? - person sara; 16.07.2016

arrow_upward
18
arrow_downward

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

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

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

И что немаловажно

Не используйте одно и то же имя для пространства имен и типа в этом пространстве имен.

Фрагментация каждых 1/2 типов в пространства имен не будет соответствовать первому требованию, так как у вас будет масса пространств имен, которые нужно будет квалифицировать или использовать, если вы будете следовать пути Visual Studio. Например

Ядро - Домен - Пользователи - Разрешения - Учетные записи

Вы бы создали

  • MyCompany.Core.Domain.Users
  • MyCompany.Core.Domain.Permissions
  • MyCompany.Core.Domain.Accounts

или просто

  • MyCompany.Core.Domain

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

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

person Chris S    schedule 17.08.2009
comment
В этой книге прямо говорится, что файловая структура должна максимально соответствовать структуре пространства имен. - person Max Schmeling; 17.08.2009
comment
Насколько это возможно, но я предполагаю, что это означает, что 2 класса в папке не требуют пространства имен, например Пространство имен помощников, пространства имен расширений. - person Chris S; 18.08.2009
comment
Если вы посмотрите на исходный код MVC aspnetwebstack.codeplex.com/SourceControl/latest#src, вы заметите, что они действительно придерживаются шаблона пространства имен папок. Классы расширений не находятся ни в каких подпапках. И любые подпапки с одним или несколькими классами имеют подпапку в пространстве имен. Интересный. - person harsimranb; 27.08.2014
comment
На самом деле, если вы посмотрите на исходный код MVC, Microsoft явно не следует этому. Во многих папках пространства имен и структура папок несколько совпадают (хотя и не строго). Это хорошо. Но в других папках пространства имен повсюду. И это правильный способ использования пространств имен. Загляните в папку src- ›Common. Пространства имен меняются почти для каждого файла. Жесткое сопоставление пространств имен с папками является плохой практикой и делает бесполезным явный выбор дизайнеров фреймворка отделять пространства имен от папок. - person Ryan Horath; 07.09.2014
comment
Похоже, что стандартная структура папок MVC ведет людей по неправильному пути. MyCompany.MyProject.Models, MyCompany.MyProject.Views и MyCompany.MyProject.Controllers начинают разваливаться, когда вы заканчиваете проект, в котором есть сотни представлений, контроллеров и моделей. Например, у меня может быть главное представление, состоящее из 20-40 частичных представлений. У каждого частичного представления может быть своя собственная модель представления. Итак, теперь у меня есть 1 контроллер, с которым связано до 40 моделей представления. Практика заключается в том, чтобы поместить все 40 этих моделей представления в одну Models папку? А теперь представьте себе 10-20 таких просмотров. - person crush; 27.03.2015

arrow_upward
10
arrow_downward

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

Кроме того, если ReSharper рекомендует это, вероятно, это хорошая идея. Например. R # будет жаловаться, если пространство имен вашего класса не соответствует имени его папки.

person Paul Sasik    schedule 17.08.2009
comment
Да, но ReSharper также добавляет свойство Namespace Provider в сетку свойств для папки. Если вы установите для него значение false, тогда папка больше не будет участвовать в пространстве имен. Это хорошо, например, для папок, содержащих сгенерированный код. - person John Saunders; 17.08.2009
comment
Хороший звонок, Джон. я никогда не замечал этого свойства. - person Paul Sasik; 17.08.2009
comment
@John: Большое спасибо за эту информацию! Это именно то, что я искал, когда нашел эту ветку. - person Adrian Grigore; 31.03.2015
comment
Есть идеи, как это можно сделать без резарпера? - person David; 01.09.2016

arrow_upward
6
arrow_downward

Папки файловой системы и пространства имен представляют собой иерархию. Мне кажется совершенно естественным совпадать с ними обоими. Я иду еще на один шаг вперед и использую соотношение 1: 1 между файлами и классами. Я даже делаю это, когда программирую на других языках, таких как C ++.

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

person Malte Clasen    schedule 17.08.2009
comment
@Malte, я привожу пример того, как я пытаюсь разделить свой код в первом параграфе моего вопроса (Модель, ViewModels, Windows и т. Д.). Но мои классы обычно имеют такие имена, как ContactWindow и ContactViewModel, поэтому очевидно, какой класс соответствует какой папке. Вот почему я сомневался в необходимости иерархических пространств имен. - person devuxer; 17.08.2009
comment
Обычно я избегаю дублирования имен, поэтому в этом случае у меня, вероятно, был бы файл ViewModels \ Contact.cs, содержащий класс ViewModels.Contact. Нет ничего плохого в использовании коротких имен классов, если пространства имен значимы. И, кстати, использование var позволяет избежать беспорядка в тексте, часто связанного с иерархиями пространств имен. - person Malte Clasen; 17.08.2009
comment
@Malte, разве это не означает, что вы в конечном итоге завершите квалификацию множества имен классов? Не сказать, что это плохо, но, похоже, это добавляет некоторой нагрузки. - person devuxer; 18.08.2009
comment
Обычно вы можете добавить операторы using для тесно связанных пространств имен, что устраняет большинство квалификаторов пространств имен. Во-вторых, вы можете использовать .NET 3.5 var для присвоения переменных. Теперь у вас осталось несколько параметров и конструкторов функций. По моему опыту, это довольно низкое число, если ваш код хорошо структурирован. Если вы часто зависите от большого количества типов в разных пространствах имен, вы можете сомневаться в макете пространства имен или зависимостях вашего класса. Это типичный случай рефакторинга. - person Malte Clasen; 18.08.2009
comment
Я обычно согласен насчет одного класса на файл. Одно исключение, которое мне нравится использовать, - это то, что у меня есть определенный класс коллекции, содержащий только члены одного класса. У меня есть эти два в одном файле, так как они очень тесно связаны. - person awe; 18.08.2009

arrow_upward
5
arrow_downward

Один из способов не следовать соглашению - создать файл в корневой папке проекта, а затем переместить его в последнюю подпапку.

Во всяком случае, мне действительно нравится это соглашение. Если я разделяю типы на папки, то, вероятно, эти типы имеют некую концептуальную группировку, связанную с папкой. Следовательно, в этом есть некоторый смысл, их пространства имен также похожи. Java использует этот подход и применяет его в своей системе пакетов. Самая большая разница в том, что VS только «предлагает» вам это, поскольку ни язык, ни среда CLR не навязывают это вам.

person Rui Craveiro    schedule 17.08.2009

arrow_upward
5
arrow_downward

Хотя я согласен со всеми остальными, что физическая структура, соответствующая логической, полезна, я должен сказать, что я также борюсь с автоматическим именованием Visual Studio. Есть полдюжины причин, по которым мне приходится переименовывать классы:

  • Я использую корневую папку "src", чтобы визуально отделить код от встроенных ресурсов.
  • Я хочу использовать разные заглавные буквы
  • Я упорядочу свой код по подпапкам для организации в пространстве имен
  • Мне нравится отделять интерфейсы от реализаций и базовых классов
  • Я чувствую это

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

person Hounshell    schedule 17.08.2009

arrow_upward
4
arrow_downward

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

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

В прошлом для меня было полезно создать файл (например, WPF UserControl) в одном месте, чтобы получить правильное пространство имен, а затем переместить его в «правильную» папку.

person micTronic    schedule 15.08.2015

arrow_upward
3
arrow_downward

До того, как пространства имен были введены в C ++, все типы C находились в глобальном пространстве имен. Пространства имен были созданы для разделения типов на логические контейнеры, чтобы было ясно, о каком типе идет речь. Это также относится к C #.

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

Папка предназначена для организации файлов на диске.

Эти три не имеют ничего общего друг с другом, однако часто бывает удобно, что имя сборки, пространство имен и имена папок совпадают. Обратите внимание, что Java сворачивает папки и пространства имен, чтобы они были одним и тем же (ограничивая свободу разработчика в организации файлов и пространств имен).

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

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

person Franklin Wise    schedule 13.04.2013

arrow_upward
2
arrow_downward

Я также чувствую боль из-за этого поведения «по умолчанию» в Visual Studio.

Visual Studio также пытается установить соответствие пространства имен / каталога, когда вы помещаете файлы LinqToSql .dbml в их собственный каталог. Каждый раз, когда я редактирую .dbml, я должен помнить:

  • откройте файл .dbml.designer.cs
  • удалите имя каталога / папки из объявления namespace

Однако есть способ остановить такое поведение. Это включает в себя создание настраиваемого шаблона класса.

person p.campbell    schedule 17.08.2009
comment
@pccampbell, у меня нестандартный шаблон не сработал. См. Конец 2-го абзаца моего вопроса. - person devuxer; 17.08.2009
comment
ИМО хуже всего то, что Visual Studio не выполняет автоматический рефакторинг пространства имен, если вы переместите его в другую папку. - person FINDarkside; 07.07.2015

arrow_upward
0
arrow_downward

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

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

Допустим, я использую Visual Studio для работы с Unity. Теперь все мои скрипты находятся в пространстве имён Assets.Scripts. Мало того, что существует бесполезное пространство имен Assets, которое теперь не содержит скриптов, но «Assets.Scripts» бессмысленны - он не описывает, к какому проекту или части проекта принадлежит исходный файл. Бесполезный.

person Sava B.    schedule 07.01.2015