номер
Я испробовал оба метода на малых и больших проектах, как с одним (мной), так и с командой разработчиков.
Я обнаружил, что самым простым и продуктивным путем было создание одного пространства имен на проект, и все классы попадают в это пространство имен. После этого вы можете свободно помещать файлы классов в любые папки проекта, какие захотите. Нет необходимости постоянно добавлять операторы использования в верхнюю часть файлов, поскольку существует только одно пространство имен.
Важно организовать исходные файлы в папки, и, по моему мнению, для этого следует использовать все папки. Требование, чтобы эти папки также соответствовали пространствам имен, не является необходимым, создает больше работы, и я обнаружил, что это на самом деле вредно для организации, потому что дополнительное бремя способствует дезорганизации.
Возьмите это предупреждение 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 и объектов
Самым большим преимуществом использования нескольких пространств имен в больших проектах, на мой взгляд, является дополнительная организация при просмотре классов в любом инструменте, который отображает классы в иерархии пространств имен. Даже документация. Очевидно, что наличие только одного пространства имен в проекте приводит к тому, что все классы отображаются в одном списке, а не разбиваются на категории. Однако лично я никогда не был озадачен или задержан из-за отсутствия этого, поэтому я не считаю это достаточно большим преимуществом для оправдания нескольких пространств имен.
Хотя, если бы я писал большую публичную библиотеку классов, тогда я , вероятно, использовал бы несколько пространств имен в проекте, чтобы сборка выглядела аккуратно в инструментах и документации.