Class.Class vs Namespace.Class用于顶级通用类库？

哪一个更容易接受（最佳实践）？：

namespace NP public static class IO public static class Xml ... // extension methods using NP; IO.GetAvailableResources ();

 public static class NP public static class IO public static class Xml ... // extension methods NP.IO.GetAvailableResources ();

同样对于#2 ，代码大小通过具有部分类来管理，因此每个嵌套类可以在单独的文件中，对于扩展方法也是相同的（除了它们没有嵌套类）

我更喜欢#2 ，原因有几个，比如能够使用已经常用的类型名称，比如IO ，我不想替换或碰撞。

你更倾向哪个？各有利弊吗？这种情况的最佳做法是什么？

编辑：两者之间是否会有性能差异？

我会说＃1。因为当你将很多类捆绑到一个静态类中时，你会做一个与命名空间相同的事情。这就是为什么我会说最好让命名空间为你做这件事。

在这种情况下，您还可以通过在需要时添加使用来摆脱必须在所有内容中编写“NP”。我认为您应该嵌套您的命名空间，以便它们不会碰撞或使用更多描述命名空间名称而不是IO。

最常见的做法是微软做的最好的做法，我从未见过他们做过＃2

我更喜欢＃1，因为它不需要我通过1个类来调用另一个类。我认为它使事情有点混乱，因为通常对象意味着有成员类，方法等直接处理通过实例化类所做的对象。这意味着你并没有真正遵循OOP的原则。微软还表示＃1是最佳做法。

我从未见过你使用过的2号。它让我想起了VB6模块。

命名空间的重点是它们用于组织代码：

命名空间在C＃程序中以两种方式大量使用。首先，.NET Framework类使用命名空间来组织其许多类。其次，声明自己的命名空间可以帮助控制较大的编程项目中的类和方法名称的范围。

当您查看.NET框架本身时，您可以看到几乎所有内容都像第一个示例（命名空间）一样构建，并且几乎没有任何内容像第二个示例（嵌套类型）那样构建。使用嵌套类型的罕见情况是，它们与外部类型紧密相关，它们本质上是它的一部分，但由于代码重用等原因需要成为一个单独的类。

因此，如果通过“最佳实践”，您的意思是“将事物用于他们设计的目的”，“最像.NET框架”和“最接近.NET设计范例”那么就没有竞争; 将名称空间用于组织，而不是嵌套类型。

关于你的编辑 – 不，没有在现实世界中重要的性能差异。

我更喜欢＃1并让命名空间来做。就像其他人所说的那样，调用课程去其他课程是非常困惑的。

此外，当您执行更复杂的事情（如reflection或使用提供者模型之类的东西）时，将嵌套类作为实际提供者部分或您尝试访问的目标变得毛茸茸。

最后，测试嵌套类和接口使测试更加困难。

我认为你应该避免暴露（公共）嵌套类和接口，或者至少这是Microsoft FxCop会说的。因此，第一个更好。

编辑:(是的，改成第一个，我不应该在我累死的时候回复）

实际上我发现自己有时使用＃2。我会在下一行之后找到原因。但在你的情况下，使用空的静态类，命名空间更理想，因为它就是它们的用途。

但是，如果您有一个用于派生新类的用例，有时可能会嵌套这些派生类。

例如，您可以：

 public abstract class Vehicle { int NumberOfWheels; } public class SportsCar : Vehicle { }

现在，您可能希望将它们都置于Vehicle名称空间下，以便父级不会混乱所有不同的派生类。但是，这是一个坏主意。

相反，嵌套它们可以为您带来所有好处：

 public abstract class Vehicle { int NumberOfWheels; public class SportsCar : Vehicle { } }