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

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

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

и т. д. и т. д.

Изменить: удалено бредовое замечание

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

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

- 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)

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

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

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

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

Если вы используете вложенные проекты, вы рискуете попасть в окна 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 лет спустя, есть ли какой-либо окончательный или лучший ответ на этот вопрос?

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

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

Как бы выглядела структура папок проекта 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 уровень на подчеркивание