C#解决方案中的命名空间和文件夹结构:应该如何组织磁盘上的文件夹? [英] Namespaces and folder structures in c# solutions: how should folders on disk be organised?
问题描述
首先，让我们同意名称空间应与文件夹结构匹配，并且每种语言人工制品都应位于其自己的文件中.
First off, let’s agree that namespace should match folder structure and that each language artefact should be in its own file.
(请参阅>解决方案中的文件夹是否应与名称空间匹配?).
下一个问题是如何在磁盘上实际组织文件夹.
假设我在A.B.C名称空间中具有ClassC，在A.B.C.D名称空间中具有ClassD.
我们还假设每个命名空间都内置在自己的程序集(项目)中，并且按照公认的最佳做法，命名空间从右到左具有依存关系(A.B.C.D可以依赖于A.B.C，而A.B.C可以依赖于A.B，而A.B可以依赖于A).我很欣赏每个命名空间不必位于单独的程序集中，但是在一般情况下，我们将在单独的程序集中包含一些命名空间，我的示例对此进行了说明.
The next question is how the folders should actually be organised on disk.
Suppose I have ClassC in the A.B.C namespace and ClassD in the A.B.C.D namespace.
Let’s also assume that each namespace is built into its own assembly (project) and that namespaces have dependencies from right to left as per accepted best practice (A.B.C.D can depend on A.B.C which can depend on A.B which can depend on A). I appreciate that each namespace doesn’t have to be in a separate assembly but in the general case we will have some namespaces in separate assemblies and my example illustrates that.
我至少可以看到两种创建文件夹树的方法-我将其称为嵌套文件夹"和平面文件夹":
I can see (at least) two ways to create the folder tree – which I’ll call "nested folders" and "flat folders":
A
--A.csproj
--B
---- A.B.csproj
---- C
------ A.B.C.csproj
------ classC.cs
------ D
-------- A.B.C.D.csproj
-------- classD.cs
A
--A.csproj
--B
----A.B.csproj
----C
------A.B.C.csproj
------classC.cs
------D
--------A.B.C.D.csproj
--------classD.cs
OR
A
--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
A
--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
您将看到我已经做了一些假设:
You will see I’ve made a few assumptions already:
- 每个项目文件都有一个基于名称空间的完全限定名称(FQN).
- 每个类文件都使用非FQN
嵌套文件夹看起来更自然(我们都喜欢层次结构)，但是在大型解决方案中可能很难导航:
Nested folders seems more natural (we all like hierarchies), but may be a bit harder to navigate in large solutions:
当您在VS中查看解决方案时，它显示的是项目的平面列表，而不是嵌套视图.这看起来更像是平面文件夹"，因此组织磁盘上的文件夹以匹配VS中的视图可能有好处.
When you look at your solution in VS, it shows a flat list of projects rather than a nested view. This looks more like "flat folders" so there may be merit in organising the folders on disk to match the view in VS.
如果查看磁盘上的每个文件夹，您将看到该项目的文件夹伪像以及命名空间的子文件夹:以C为例:
If you look in each folder on disk you will see the folder artefacts for that project plus the sub folder for the namespace: taking C as an example:
C
--bin
--D
--obj
-属性
--A.B.C.csproj
--classC.cs
C
--bin
--D
--obj
--Properties
--A.B.C.csproj
--classC.cs
根据D的真实姓名，可能不是很明显D是C名称空间中的名称空间文件夹而不是组织文件夹.
Depending on D’s real name it may not be obvious that D is a namespace folder rather than an organisational folder in the C namespace.
我知道从.NET(8年前或9年前)和Java的第一天开始就有文件夹和名称空间，但是就个人而言，我们似乎并未就最佳实践项目达成共识大型解决方案的组织.我真的很想知道大家的想法.
I know we’ve had folders and namespaces from day one in .NET (8 or 9 years ago) and Java before that, but, personally speaking, we don’t appear to have come to a consensus on best practice project organisation for large solutions. I’d be really interested to find out what you all think.
谢谢
迈克尔
推荐答案
我使用统一方法.我发现嵌套层次结构太难维护了.我将我的项目分为几个解决方案，并考虑到最大的可重用性和交叉引用，并始终认为这是令人满意的.示例(项目缩进):
I use the flat approach. I find a nested hierarchy too hard to maintain. I group my projects into several solutions, with maximum reusability and cross-referencing in mind, and always found this satisfactory. Example (projects are indented):
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
等等
删除了废话
这篇关于C#解决方案中的命名空间和文件夹结构:应该如何组织磁盘上的文件夹?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
