我知道已经存在一个post，描述几乎相同，但我认为我的有点不同。
我想知道的是，您如何根据分配命名空间来组织扩展方法。目前 - 对于我们框架中的扩展方法 - 我使用以下命名空间模式
在里面我有扩展方法类。这对我来说很好，缺点是我们的软件开发人员无法立即看到扩展程序。考虑我有一个 StringExtender 类的情况，它提供了一个非常方便的 extension method "In" 扩展 String 对象。有了上面提到的命名空间的扩展方法，我们的程序员将看不到扩展方法，除非他们明确地包含它的命名空间。相反，如果我将扩展方法放在System 命名空间中，每个人都会立即看到它，但我有read that this is bad practice。
所以我的问题是您如何推广您的扩展方法 s.t.它们被您的开发人员使用。
【问题讨论】：
标签： c# extension-methods
我们将它们全部放在自己的命名空间Company.Common.Extensions 中。这样，如果你有我们的任何扩展方法，你就拥有了它们。另外，至少在我的商店，我们不必担心我们的开发人员不知道扩展方法。我有相反的担心，扩展方法过载！ :)
【讨论】：
这里的问题不是命名空间的命名，而是缺乏文档和开发人员的教育。
将它们放在任何有意义的命名空间中，写一篇 wiki 文章记录您的所有扩展方法，然后向您的开发人员发送一封电子邮件，其中包含指向该 wiki 文章的链接。
【讨论】：
这不是命名空间问题，而是通信问题。
如果这些方法有用，您需要将其传达给开发人员，相反，根据他们的反馈采取行动（具有适当的判断力）。
将任何东西放入 System 命名空间都会导致以后的灾难和混乱。您唯一想做的就是将功能“向后移植”到旧框架中，然后您可能不应该自己做，而应该使用 LinqBridge 之类的东西来做。
要警惕将所有扩展都放到一个命名空间中的愿望，除非它们真的一起广泛有用。一些开发人员可能会在被所有东西和厨房水槽通过智能感知轰炸的情况下发现树木丢失的木材。
在命名空间中保留公司名称通常是明智的，以避免混淆。
【讨论】：
@Juri- 如果您考虑一下，这与开发人员知道 .NET 框架中存在 X 类存在相同的问题。沟通是所有团队成员使用正确类的关键，无论是扩展方法还是其他帮助器。
正如 JP 所说，我经常在名为 Extensions 的某种子文件夹中看到扩展方法。希望当您声明您使用 my.company.web.utils 时，命名空间实际上是 Pascal 大小写的？
即使你把它们放在一个好的地方，也不能 100% 保证其他开发者会使用它们。
【讨论】：
假设您使用 Visual Studio，一种方法是创建自定义类模板（或修改默认模板），这样每当开发人员创建新的类文件时，它就会自动在您的命名空间中使用 using 语句。见Customize Visual Studio 2005 Templates for Coding Productivity。
【讨论】：
是的，我认为将扩展方法放在自己的公司命名空间中是最佳实践。放到 System 命名空间是懒惰的操作
【讨论】：
我很笨，懒惰和简约，所以我把它们放在与它们扩展的类型相同的命名空间中。这样就不需要额外的 using 声明、文档或通过电子邮件发送有关它们的信息 (Winston)。
【讨论】：
我喜欢 ReSharper 解决这个问题的方式。
ReSharper 会发现任何可用的扩展方法，即使没有相应的使用。如果 using 不存在，Intellisense 还会显示扩展所在的命名空间，明确扩展的来源和，表明选择它将添加 使用。 （以下示例。）
当然，仅包括当前项目可访问的命名空间，即直接或间接引用的命名空间。
如果有两种扩展方法，以下是 Intellisense 可能显示的示例。第一个来自我们已经包含的命名空间。第二个来自我们尚未（尚未）包含的命名空间。
AddMvcAddEntityFrameworkSqlServer (Microsoft.Extensions.DependencyInjection)【讨论】：
我们将所有内容放在同一个命名空间和类中，但是我们使用部分类来保持它们的组织性。
例如：
ExtensionMethods-String.cs
ExtensionMethods-DataObject.cs
ExtensionMethods-Debug.cs
...等都有部分类...
【讨论】：
您可以通过将扩展方法放在全局命名空间中来实现您想要的。这就是我所做的，然后它们就可以在不需要任何 using 语句的情况下使用。
【讨论】：
string#IsEmpty(this string str) 这样的随机扩展方法会“莫名其妙地”出现或消失。