соглашение - .net пространства имен в проектах с физическими папками

Question

Предположим, у меня есть проект .NET с именем GhostJago.WebScraper

. В этом проекте у меня есть файл, содержащий класс WebScrapeEngine.Класс содержится в namespace GhostJago.WebScraper {...}.

Теперь я добавляю новую папку и помещаю в нее файл класса.Моя структура в основном:

GhostJago.WebScraper (Project)
 |-> AddIns (folder)
    |-> WebScraperAddIn.cs (c# file)
 |-> WebScraperEngine.cs (c# file)

Вопрос: Должно ли пространство имен в WebScraperAddIn.cs быть namespace GhostJago.WebScraper.AddIns {...} или это не имеет значения?

Answer 1

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

Я работал над системой, которая работала с широким спектром продуктов несколько лет назад.,Все это было в папке Company.System.Products.Фактически, многие из классов в этой папке также имели несколько классов в одном файле cs.

К тому времени, когда было 150 продуктов, регулярно происходило следующее:

1. Этостало трудно найти что-либо
2. Стало трудно (с точки зрения объединения при регистрации) людям работать над продуктами аналогичного типа (хотя это не проблема пространства имен, это организационная проблема)
3. Люди запутались;где я могу добавить что-то новое?
4. Люди, не знакомые с проектом, не знали, с чего начать

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

Таким образом, наличие определенной степени организации в вашем проекте может упростить задачу!

Answer 2

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

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

Answer 3

Отображение пространств имен в имена папок является чисто условным.Его цель - облегчить поиск исходного кода в более крупных проектах.

При этом нет особой выгоды или необходимости с технической точки зрения для этого.Другими словами, это не имеет значения.

Answer 4

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

Answer 5

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

РЕДАКТИРОВАТЬ:

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

соглашение - пространства имен .net в проектах с физическими папками