我正在使用ASP.NET MVC项目，每次将类添加到文件夹时，它都会占用很长的名称空间。

例子：

Project = Tully.Saps.Data  
Folder = DataAccess/Interfaces  
Namespace = Tully.Saps.Data.DataAccess.Interfaces

Folder = DataAccess/MbNetRepositories  
Namespace = Tully.Saps.Data.DataAccess.MbNetRepositories

问题：
最好是不保留名称空间，并在访问它的类中添加using子句，或者将该项目中所有内容的名称空间更改为Tully.Saps.Data吗？

解决方案

回答

别管它们并添加用法。我们在手动更改此类内容时遇到麻烦(难以调试，与其他项目不一致等)。

回答

实际取决于我们如何处理它。如果我们只打算访问一次或者两次命名空间成员，那么添加" using"语句确实对我们没有多大帮助。

如果要多次使用它，那么减少名称空间链可能会使事情更容易阅读。

我们总是可以更改名称空间，因此，如果我们只是想在逻辑上将文件分组在一起而不创建新的名称空间，则它不会添加新的文件夹名称。

回答

根据FXCop，我同意：

Avoid namespaces with few types
  
  A namespace should generally have more than five types.

也(这适用于"单一名称空间"建议-几乎与没有名称空间的说法相同)

Declare types in namespaces
  
  A type should be defined inside a namespace to avoid duplication.

回答

• 命名空间

名称空间可帮助我们在对象模型或者应用程序中定义一组实体的"作用域"。这使它们成为软件设计决策，而不是文件夹结构决策。例如，在MVC应用程序中，拥有Model / View / Controller文件夹和相关的命名空间是很有意义的。因此，尽管在某些情况下文件夹结构可能会匹配我们决定在开发中使用的命名空间模式，但这不是必需的，也可能不是我们想要的。每个名称空间都应视情况决定

• 使用语句

为名称空间定义using语句是一个单独的决定，该决定取决于该名称空间中的对象在代码中被引用的频率，并且不应以任何方式影响我们的名称空间创建实践。

回答

别管它。这是IDE如何决定编码风格的一个很好的例子。

回答

仅仅因为我们使用的工具(Visual Studio)已经确定每个文件夹都需要一个新的命名空间，并不意味着我们需要这样做。
我个人倾向于将"数据"项目保留为单个命名空间。如果我有一个名为" Model"的子文件夹，那么我不希望这些文件位于Something.Data.Model命名空间中，而是希望它们位于Something.Data中。