C# 文件夹结构#

项目文件中的文件夹结构在这里已经讨论了好几次，但我想进一步缩小这个问题的范围。比如说，我的项目是以下面的方式组织的，并带有各自的名称空间

[Project 1]  

[A(Folder)]    
   Class A             ConceptCheck.ClassA
   [B(Folder)] 
     Class B           ConceptCheck.ClassA.ClassB
[C(Folder)]
   Class C             ConceptCheck.ClassC

using ConceptCheck.ClassA;
using ConceptCheck.ClassB;
using ConceptCheck.ClassA.ClassC;

            A a = new A();
            B b = new B();
            C c = new C();

因此，当我创建如下对象时，我需要包含所有名称空间

[Project 1]  

[A(Folder)]    
   Class A             ConceptCheck.ClassA
   [B(Folder)] 
     Class B           ConceptCheck.ClassA.ClassB
[C(Folder)]
   Class C             ConceptCheck.ClassC

using ConceptCheck.ClassA;
using ConceptCheck.ClassB;
using ConceptCheck.ClassA.ClassC;

            A a = new A();
            B b = new B();
            C c = new C();

---

例如，如果它有少量的名称空间，我可以很容易地做到这一点。我想知道如果名称空间的数量很大，最好的方法是什么？这样包含名称空间是最好的方法吗

如果没有遵循前面所说的内容，我认为最好不要以文件夹甚至项目命名名称空间，而是以这样一种方式命名，即包含逻辑上属于一起的类（从系统/功能的角度）

例如，您可能有几个项目，每个项目实现一个特定的外部API。功能相似，为您的系统做相同的事情，只是风格不同。比如银行对账单下载。您的项目结构可能如下所示：

Project BankA 
   class BankADownloader
Project BankB 
   BankBDownloader
   HelperA
   ExtensionsB
Project BankC
   ...

对所有这样的项目使用相同的名称空间是有意义的，例如MySystem.StatementDownloaders

我给出了一个更广泛的例子——多个项目——的观点。但这会对一个包含多个文件夹的项目施加全部影响。要使用my Bank Statement Downloader示例，您可能希望（按银行）将类和其他工件组织到文件夹中，但名称空间IMO应该反映公共功能（或其他逻辑体系结构透视图，如应用层），而不是文件夹组织

---

我希望我没有误解你的问题。

你的问题似乎很好。名称空间的数量不会降低性能，通常也不会降低开发速度。另外，你可以从这篇文章中得到启发：我同意你的观点。我们应该根据功能进行组织。我同意名称空间应该根据其包含的对象的逻辑功能分组来命名。但我想知道，为什么文件夹的名称应该不同呢？