.NET：您如何决定如何构造名称空间？

我想知道你们用什么准则来确定名称空间的结构。你什么时候决定它是自己的名称空间

我在一篇论坛讨论或文章中读到，最好的做法是选择一个具有尽可能少的子名称空间的浅树，但不记得背后的原因或链接

现在我只是在做“感觉正确”的事情，但我更喜欢一些更具体的指导方针，特别是向新开发人员解释

---

谢谢。

微软已经

我自己也喜欢浅树法。许多分层名称空间的负面后果之一是在单个项目中大量使用相同名称和相同功能的类（仅因名称空间位置不同而有所区别），甚至更糟的是：在同一项目中使用相同名称和不同功能的类。在一个项目中只有一个名称空间迫使开发人员为每个单独的类提供一个良好的、自描述性的名称

但是，在一个项目中拥有多个文件夹仍然是一个好主意（出于组织目的），我希望在Visual Studio中有一个选项，使添加到子文件夹中的类不能自动将文件夹名称添加到它们的名称空间中（在比2005年更新的版本中可能有这样的选项）。我总是在根级别添加新类，然后将它们拖到相应的文件夹中来解决这个问题。

我在解决方案中使用多个文件夹（多级文件夹），有时在项目中使用

我将解决方案文件夹映射到名称空间，有时给项目一个子名称空间

我的大多数项目都有一个名称空间

例如

---

我同意MusicGenesis关于好名字重要性的观点，并建议阅读微软的指南（最好是C#3.5或4.0）。

@Nicholas。我更感兴趣的是如何构造名称空间树，而不是实际的命名。例如，如果您正在编写一组继承基本解析器的解析器，您是将所有解析器放在一个名称空间中，还是为每个子类解析器创建一个子名称空间？这类事情。我理解，但这是一个开放的问题。我可以向您指出设计它的专家/人员所说的，但最终取决于您（或您的团队）的开发风格。什么最有效？什么最有意义？

Company.Product.Initialization // (exe project)
Company.Product.Data.Interfaces // interfaces (dll)
Company.Product.Data.Collections // collections (dll)
Company.Product.Data.Binding // binding logic (dll)
Company.Product.Data.Binding.Tests // unit tests for above (dll)
Company.Product.Data.Serialization
Company.Product.Data.Serialization.Tests
Company.Product.Model // (dlls)
Company.Product.Gui.Controls // (dlls)
Company.Product.Gui.Windows // (dlls)
Company.Product.Gui.ModelView // (dlls)
Company.Product.Gui.Logic // (dlls)