Пространства имен и структуры папок в решениях C#: как должны быть организованы папки на диске?

«Прежде всего, давайте согласимся, что пространство имен должно соответствовать структуре папок и что каждый языковой артефакт [sic] должен находиться в отдельном файле».

Забавно, вот как пакеты работают в Java. Я всегда думал, что разрыв связи между пространствами имен и структурой каталогов считался одним из улучшений, внесенных C#. Это не правда? (Простите за незнание, я Java-человек.)

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

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

Вот как я это делаю:

- DataHelpers\
---Factory\
---DataAccess\
---...
- Components\
--- EmailProcessor\
--- ErrorLogger\
- Desktop\
--- WindowsApp1\
- Services\
--- WindowsService1\
--- WindowsService2\
- WebApps\
--- WebApp1\
--- WebApp2\

Теперь внутри каждого крупного приложения, которое у меня есть, например:

- WindowsService1\
--- WindowsService1\ (this contains all *.cs, bin, obj, etc and .csproj file)
--- Solution\ (this contains the .sln file where you link to other projects like ErrorLogger, etc)

Надеюсь это имеет смысл!

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

CompanyName
  CompanyName.Core
    Class1
    Struct2
    Enum3
  CompanyName.Data
  CompanyName.Web

CompanyName.Projects
  CompanyName.Projects.Core

CompanyName.Projects.ProjectX
  CompanyName.Projects.ProjectX.Core
  CompanyName.Projects.ProjectX.Website
  CompanyName.Projects.ProjectX.ToolY

и т. д. и т. д.

Обновлено: удалено бредовое замечание

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

Если вы используете вложенные проекты, вы рискуете столкнуться с проблемой Windows MaxPath. Это серьезный отказ от использования вложенных структур. Только представьте, что встречаетесь с этим маленьким Gem на полпути через проект разработчика, когда вам нужно называть проекты VS трехбуквенными акронимами, чтобы не попасть в MaxPath. Ошибка MS послужила источником вдохновения для названий ваших сборок. Что это было бы за шутку. Работать с плоскими конструкциями намного удобнее со всех сторон.

   -SouceControlFolderName
     -Project1
       -Src
         -Main
           -Company.Project1.AppName
             *Company.Project1.AppName.sln
             *Company.Project1.AppName.Tests.sln
             -Company.Project1.AppName.Common
             -Company.Project1.AppName.Common.Tests
             -Company.Project1.AppName.Entities
             -Company.Project1.AppName.Entities.Tests
             -Company.Project1.AppName.Security
             -Company.Project1.AppName.Security.Tests
             -etc.

Вы можете создать отдельный каталог для тестовых проектов или, как указано выше, и иметь их все вместе, что легче управлять при добавлении в систему управления версиями, то есть Subversion (TFS во многих отношениях лучше, за исключением того факта, что ему нужна интеграция с Explorer, а не только интеграция с VS и настоящий оффлайн рассказ)

Я предпочитаю плоскую структуру с проектами в корне.

• MyCorp.Core
• MyApp.Domain
• MyApp.Data
• MyApp.UI
• MyApp.Test

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

12 лет спустя, есть ли какой-либо окончательный или лучший ответ на этот вопрос?

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

"agree that namespace should match folder structure and that each language artefact should be in its own file."

Как бы выглядела структура папок проекта A.B.C.csproj, если бы он расширял код из других пространств имен, например:

• прародитель: A.csproj
• родитель: A.B.csproj
• дочерний A.B.C.D.csproj
• внешние пространства имен System.Linq или Microsoft.Extensions.Logging

Возможно что-то вроде:

/A                                  // namespace: A
  /B                                // namespace: A.B
    /C                              // namespace: A.B.C
      A.B.C.csproj 
      ClassC.cs                  
      /_                            // External Namespace root folder (underscore with no text)
        /System                     // namespace: System 
          /Linq                     // namespace: System.Linq
            IQueryableExtensions.cs 
        /Microsoft                  // namespace: Microsoft
          /Extensions               // namespace: Microsoft.Extensions
            /Logging                // namespace: Microsoft.Extensions.Logging
              ILoggerExtensions.cs                                  
      /__A                          // namespace: A (Grand Parent folder (2 underscores for 2 levels up)
        ClassAExtensions.cs
        /B                          // namespace: A.B (Nested Parent folder)
          ClassBExtensionsNested.cs
                                    //Parent Namespace folder (1 underscore for 1 level up)
      /_B                           // namespace: A.B
        ClassBExtensions.cs
      /D                            // namespace: A.B.C.D (Child folder)
        ClassDExtensions.cs

Выше пытается продемонстрировать:

• Папка с одиночным подчеркиванием (_) без следующего текста будет заменена пустым пространством имен и новым корнем для всех внешних пространств имен.
• Папки с нижним подчеркиванием (__A) и (_B), за которыми следуют текстовые заменители на уровень выше в дереве / иерархии текущего проекта. 1 уровень на подчеркивание