我喜欢在开发时保持井井有条,将相关的* .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的一部分.