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