我正在使用ASP.NET MVC项目，每次向类文件夹添加一个类时，它都会生成很长的命名空间。C＃中的命名空间＃
例：
Project = Tully.Saps.Data
Folder = DataAccess/Interfaces
Namespace = Tully.Saps.Data.DataAccess.Interfaces
Folder = DataAccess/MbNetRepositories
Namespace = Tully.Saps.Data.DataAccess.MbNetRepositories
问题：
它是最好的独自离开命名空间和使用条款的添加到访问或更改命名空间Tully.Saps.Data类在这个项目中的一切？
让他们独自一人，并添加使用。你需要手动修改这些东西（比较难以调试，与其他项目不一致等）。
这真的取决于你如何处理它。如果你只打算访问一个或两个命名空间的成员，那么添加“using”语句对你来说确实没有多大作用。
如果你打算多次使用它，那么缩小命名空间链可能会使事情更容易阅读。
如果您只是想在逻辑上将文件组合在一起而不创建新的名称空间，则您可以随时更改名称空间，以便它不添加新的文件夹名称。
根据FxCop的，我同意：
避免命名空间有几种类型
命名空间通常应该有超过类型。
也（这也适用于“单一命名空间”的建议 - 这是几乎同样为没有命名空间说吧）
声明类型的命名空间
一类型应该在命名空间内定义以避免重复。
.Namespaces帮助我们定义我们的对象模型或我们的应用程序的一组实体的“范围”。这使得他们成为软件设计决策而不是文件夹结构决策。例如，在MVC应用程序中，具有Model/View/Controller文件夹和相关命名空间是很有意义的。因此，在某些情况下，尽管文件夹结构可能与我们决定在开发中使用的命名空间模式相匹配，但这不是必需的，也可能不是我们所期望的。每个命名空间应该使用的语句这样的情况，逐案
定义使用语句命名空间是基于多久该命名空间中的物体将被称为在一个单独的决定代码，不应以任何方式影响我们的命名空间创建实践。
给它。这是您的IDE如何规定您的编码风格的一个很好的例子。
仅仅因为你使用的工具（Visual Studio）已经决定每个文件夹需要一个新的名称空间并不意味着你这样做。
我个人倾向于将我的“数据”项目作为单个命名空间离开。如果我有一个名为“Model”的子文件夹，我不想在Something.Data.Model命名空间中使用这些文件，我希望它们在Something.Data中。