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