c#解决方案中的命名空间和文件夹结构:如何组织磁盘上的文件夹？

首先,让我们同意命名空间应该匹配文件夹结构,并且每个语言工件应该在它自己的文件中.

(请参阅解决方案中的文件夹是否应与命名空间匹配？).

接下来的问题是如何在磁盘上实际组织文件夹.
假设我在ABC命名空间中有ClassC,在ABCD命名空间中有ClassD.
我们还假设每个命名空间都构建在它自己的程序集(项目)中,并且命名空间根据公认的最佳实践从右到左依赖(ABCD可以依赖于ABC,它可以依赖于AB,它可以依赖于A).我感谢每个命名空间不必在一个单独的程序集中,但在一般情况下,我们将在单独的程序集中有一些命名空间,我的例子说明了这一点.

我可以看到(至少)两种创建文件夹树的方法 - 我称之为"嵌套文件夹"和"平面文件夹":

1 - 嵌套文件夹:

甲
--A.csproj
--B
---- ABcsproj
----Ç
------ ABCcsproj
------ classC.cs
------ d
-------- ABCDcsproj
-------- classD.cs

要么

2 - 扁平文件夹:

A
--A.csproj
AB
--ABcsproj
ABC
--ABCcsproj
--classC.cs
ABCD
--ABCDcsproj
--classD.cs

你会看到我已经做了一些假设:

每个项目文件都具有基于命名空间的完全限定名称(FQN).

每个类文件都使用非FQN

嵌套文件夹似乎更自然(我们都喜欢层次结构),但在大型解决方案中导航可能有点困难:

当您在VS中查看解决方案时,它会显示项目的平面列表,而不是嵌套视图.这看起来更像是"平面文件夹",因此在磁盘上组织文件夹以匹配VS中的视图可能是有好处的.

如果查看磁盘上的每个文件夹,您将看到该项目的文件夹文件加上命名空间的子文件夹:以C为例:

ç
--bin
--D
--obj
--properties
--ABCcsproj
--classC.cs

根据D的真实名称,D可能并不明显是命名空间文件夹而不是C命名空间中的组织文件夹.

我知道我们在.NET(8或9年前)和Java之前的第一天就有文件夹和命名空间,但是,就个人而言,我们似乎没有就大型的最佳实践项目组织达成共识解决方案.我真的很想知道你们都在想什么.

谢谢
迈克尔

我使用平面方法.我发现嵌套的层次结构太难维护了.我将我的项目分组到几个解决方案中,并考虑到最大的可重用性和交叉引用,并始终认为这是令人满意的.示例(项目缩进):

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)

我希望这是有道理的!