c# - c# 解决方案中的命名空间和文件夹结构 : how should folders on disk be organised?

Question

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

(参见 Should the folders in a solution match the namespace?)。

下一个问题是文件夹实际上应该如何在磁盘上组织。
假设我在 A.B.C 命名空间中有 ClassC，在 A.B.C.D 命名空间中有 ClassD。
我们还假设每个命名空间都内置到它自己的程序集(项目)中，并且命名空间按照公认的最佳实践从右到左具有依赖关系(A.B.C.D 可以依赖于 A.B.C，A.B.C 可以依赖于 A.B，A.B 可以依赖于 A)。我很欣赏每个命名空间不必位于单独的程序集中，但在一般情况下，我们将在单独的程序集中有一些命名空间，我的示例说明了这一点。

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

1 - 嵌套文件夹:

一个
--A.csproj
--乙
----A.B.csproj
----C
------A.B.C.csproj
------classC.cs
------D
--------A.B.C.D.csproj
--------classD.cs

或

2 – 平面文件夹:

一个
--A.csproj
A.B
--A.B.csproj
A.B.C
--A.B.C.csproj
--classC.cs
A.B.C.D
--A.B.C.D.csproj
--classD.cs

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

• 每个项目文件都有一个基于命名空间的完全限定名称 (FQN)。
• 每个类文件都使用一个非FQN

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

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

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

C
--bin
--D
--对象
--属性
--A.B.C.csproj
--classC.cs

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

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

谢谢
迈克尔

Answer 1

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

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

等等等

编辑:删除废话