扩展方法名称空间和赞助商类的命名约定答案

【问题标题】：Naming conventions for extension method namespaces and sponsor classes扩展方法名称空间和赞助商类的命名约定
【发布时间】：2010-11-06 06:27:24
【问题描述】：

您对命名空间和赞助商类使用了哪些命名约定？（即包含扩展方法定义的类）

是否有标准/推荐的 .NET Framework 命名约定？（“框架设计指南，第 2 版”一书仅提供了关于不使用哪些命名空间的指导）。

【问题讨论】：

【解决方案1】：

我还没有看到任何官方推荐，但我一直在组织我的扩展类，比如 [NameSpace]。[ClassName]Extensions：

ProjectName.Web.Util.ControlExtensions
ProjectName.Data.Util.CollectionExtensions

【讨论】：

我也这样做，我还要补充一点，我倾向于将任何高度专业化的静态扩展方法类放入相关的命名空间中，以便它们将被使用，这样它们就不会为其他人混淆智能感知开发商。所以换句话说，我的扩展方法类不一定与它们扩展的类在同一个命名空间中。
我做了类似的事情，但是当我将扩展方法添加到 interface 而不是类时，我最终会得到像 IMyInterfaceExtensions 这样难看的类名，它看起来像extensions 类本身就是一个接口 :(

【解决方案2】：

对于命名空间 - 我将关注命名空间名称的标准框架指南。将扩展方法放入通常有意义地使用/关联它们的命名空间中，并避免为此使用额外的命名空间。

对于赞助商类 - 在这种情况下，它相当不重要。我会尝试选择一个有意义的类名，但似乎没有固定的指导方针。

不过，重要的是，扩展方法的用户永远不会真正直接使用/看到赞助商类。只要已包含命名空间，就可以正确找到扩展方法。我个人在我的扩展方法中使用了与jrummell 非常相似的东西，但微软在框架中没有遵循这一点（一个很好的例子是Enumerable 类）。

【讨论】：

Reed 和 jrummell 的答案都很好。我将把这个标记为“The”答案，因为它更深入。不过需要注意的是 - 赞助商类名称在不支持扩展方法的 .NET 语言中确实很重要，其中必须使用经典的静态方法调用。