C#命名空间/文件夹：何时过于有组织/创建太多名称空间不对？

我喜欢在开发时保持井井有条,将相关的* .cs分组到他们自己的文件夹中：

->Project
--->Enums
--->Exceptions
--->Extensions
--->Providers
--->Configuguration
--->Design
--->etc.
  Manager.cs

众所周知,默认情况下,Visual Studio会为每个文件夹创建一个新的命名空间：

Company.Product.Enums.MyEnumClass.cs
...
Company.Product.Exceptions.ExceptionBase.cs
etc.

哪个有优点和缺点.

好的一面是,通过intellisense,弄清楚程序集的设计方式变得微不足道：你可以看到所有部分,只看到你想要的部分(与每个类,枚举,静态扩展条款,业务实体,经理相比),提供者等都在一个命名空间中.

缺点是……你最终不得不使用一堆真正的包含来编码.

using Company.project.Enums;
using Company.project.Model;
using Company.project.Extensions;
...
etc.

这种工作方式存在问题……随着扩展而变得非常明显……这是其中一个很明显我正在进行此操作的方式并不是很好(很容易忘记使用Extensions,并且不知道已经有方法可以做我想要的……)

所以……一方面,我可以选择按照我多年来一直保持的方式保持井井有条,并允许Intellisense成为装配的新用户快速掌握其功能的方式,而且只是将它归为包含…,另一种方法是将所有内容放在一个命名空间中…并编写关于如何开始使用程序集的良好文档…(更多的成本/老实说,可能永远不会为小项目等)

关于命名空间的官方MSDN文档没有给出关于走哪条路的建议：
http://msdn.microsoft.com/en-us/library/893ke618(VS.71).aspx

因此,在我改变方式之前,我对其他人正在做的事情非常感兴趣,为什么……你在做什么,为什么呢？

解决方法

我认为你的组织不正确.不要通过枚举/扩展等组织.按组织的使用方式进行组织.将相关类型放在一起.

此外,您引用的指南来自.NET 1.1的时代！线索是URL中的V7.1.正确的参考是Names of Namespaces,这是Design Guidelines for Developing Class Libraries的一部分.