最佳实践：C# 扩展方法命名空间和推广扩展方法
我知道已经存在一个 帖子，描述了几乎一样的，但我觉得我的有点不同。
我想知道的是您如何在分配命名空间方面组织扩展方法。 目前，对于我们框架中的扩展方法，我使用以下命名空间模式
- MyCompany.Web.Utils
，并且在内部有扩展方法类。 这对我来说很好，缺点是我们的软件开发人员无法立即看到扩展程序。 考虑一下我有一个 StringExtender 类的情况，它提供了一个非常方便的 扩展方法“In”，扩展String对象。 拥有具有上述命名空间的扩展方法，我们的程序员将不会看到扩展方法，除非他们显式包含其命名空间。 相反，如果我将扩展方法放在 System 命名空间中，每个人都会立即看到它，但我已经 请注意这是不好的做法。
所以我的问题是，您如何推广开发人员使用的扩展方法。
I know there exists already a post, describing nearly the same, but I think mine is a bit different.
What I would like to know is how you organize your extension methods in terms of assigning the namespace. Currently - for the extension methods in our framework - I use the following namespace pattern
- MyCompany.Web.Utils
and inside I have the extension method classes. This is fine for me with the disadvantage that the extenders are not immediately visible to our software developers. Consider the case where I have a StringExtender class which provides a quite handy extension method "In" that extends the String object. Having the extension method withing the above mentioned namespace, our programmers won't see the extension method unless they explicitly include its namespace. Instead, if I would put the extension method in the System namespace, everyone would immediately see it, but I've read that this is bad practice.
So my question is how you do promote your extension methods s.t. they are used by your developers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
这不是命名空间问题，而是通信问题。
如果这些方法有用，您需要将其传达给开发人员，相反，根据他们的反馈采取行动（具有适当的判断水平）。
将任何东西放入 System 命名空间将会导致以后的灾难和混乱。 您唯一想要执行此操作的时候是将功能“向后移植”到旧框架中，然后您可能不应该自己执行此操作，而应该使用 LinqBridge 之类的工具来执行此操作。
警惕将所有扩展放入同一个名称空间的愿望，除非它们确实可以广泛使用。 如果一些开发商通过智能感知受到所有东西和厨房水槽的轰炸，他们可能会发现树木失去了木材。
一般来说，将名称空间保留为公司名称是明智的，以避免混淆。
This is not a namespace problem it is a communication problem.
If these methods are useful you need to communicate this to the developers and, conversely, act on the feedback from them (with appropriate levels of judgement).
Placing anything into the System namespace is a recipe for disaster and confusion later. The only times you ever want to do this is to 'back port' functionality into older frameworks and then you probably shouldn't do it yourself but should use something like LinqBridge to do it.
Be wary of the desire to throw all extensions into one namespace unless they really are widely useful together. Some developers may find the wood lost for the trees if they are bombarded with everything and the kitchen sink via intellisense.
Keeping the namespace the company name is sensible in general to avoid confusion.
这里的问题不是命名空间的命名，而是开发人员缺乏文档和教育。
将它们放在任何有意义的命名空间中，编写一篇 wiki 文章，记录所有扩展方法，然后向开发人员发送一封电子邮件，其中包含 wiki 文章的链接。
The problem here is not the naming of the namespace, it's the lack of documentation and education of your developers.
Put them in whatever namespace makes sense, write a wiki article documenting all your extension methods, then send an email to your developers with a link to the wiki article.
我们将它们全部放在自己的命名空间
Company.Common.Extensions中。 这样，如果您有我们的任何扩展方法，您就拥有了它们。 另外，至少在我的店里，我们不必担心我们的开发人员不了解扩展方法。 我有相反的担忧，扩展方法过载！ :)We put them all in their own namespace
Company.Common.Extensions. That way, if you have any of our extension methods, you have them all. Plus, at least at my shop, we don't have to worry about our developers not knowing about extension methods. I have the opposite worry, extension method overload! :)假设您使用 Visual Studio，一种方法是创建自定义类模板（或修改默认类模板），以便每当开发人员创建新的类文件时，它都会自动具有带有您的命名空间的 using 语句。 请参阅自定义 Visual Studio 2005 模板以提高编码效率 。
Presuming you use Visual Studio, one way would be to create a custom Class template (or modify the default one) so that whenever a developer creates a new class file it automatically has a using statement with your namespace(s). See Customize Visual Studio 2005 Templates for Coding Productivity.
@Juri-如果您考虑一下，这与开发人员知道 .NET 框架中存在类 X 存在同样的问题。 沟通是所有团队成员使用正确的类的关键，无论是扩展方法还是其他帮助者。
正如 JP 所说，我经常在某种名为 Extensions 的子文件夹中看到扩展方法。 希望当您声明使用 my.company.web.utils 时，命名空间实际上是 Pascal 大小写？
即使您将它们放在一个好的地方，也不能 100% 保证其他开发人员会使用它们。
@Juri- If you think about it this is the same problem as developers knowing that class X exists in the .NET framework. Communication is key that all team members use the right classes, be they extension methods or some other helper.
As JP has stated, I often see extension methods in some kind of subfolder called Extensions. Hopefully when you state you use my.company.web.utils the namespace is actually Pascal cased?
Even if you put them in a good place there is no 100% guarantee that other developers will use them.
我们将所有内容放入相同的命名空间和类中，但是我们使用部分类来保持它们的组织性。
例如：
...等都有部分类...
We put everything into the same Namespace and Class, however we use partial classes to keep them organized.
For example:
...etc all have partial classes...
您可以通过将扩展方法放入全局命名空间来实现您想要的目的。 这就是我所做的，然后它们就可以使用，而不需要任何
using语句。You can achieve what you want by putting extension methods in the global namespace. That's what I do and they're then available without needing any
usingstatements.我喜欢 ReSharper 解决这个问题的方式。
ReSharper 会发现任何可用的扩展方法，即使没有相应的使用。 如果 using 不存在，Intellisense 还会显示扩展程序所在的命名空间，明确扩展程序的来源和，表明选择它将添加 使用。 （下面的示例。）
当然，只包括当前项目可访问的命名空间，即直接或间接引用的命名空间。
以下是如果有两种扩展方法，Intellisense 可能会显示的示例。 第一个来自我们已经包含的命名空间。 第二个来自我们尚未包含的命名空间。
AddMvcAddEntityFrameworkSqlServer（Microsoft.Extensions.DependencyInjection）I like the way ReSharper solves this problem.
ReSharper discovers any available extension methods, even without the corresponding usings. In case the using is not present, Intellisense also shows the namespace where the extension resides, making clear where the extension comes from and indicating that selecting it will add the using. (Example below.)
Naturally, only namespaces reachable by the current project, i.e. directly or indirectly referenced, are included.
Here is an example of what Intellisense might show if there are two extension methods. The first one comes from a namespace that we have already included. The second comes from a namespace that we have not (yet) included.
AddMvcAddEntityFrameworkSqlServer (Microsoft.Extensions.DependencyInjection)我很笨、很懒、很简约，所以我把它们放在与它们扩展的类型相同的命名空间中。 这样就不需要额外的使用声明、文档或电子邮件（Winston）。
I'm dumb, lazy and minimalistic, so I put them at the same namespace as the type they extend. In this way there is no need for extra using statements, documentation or emailing about them (Winston).
是的，我认为将扩展方法放在自己的公司名称空间中是最佳实践。 把它放在系统命名空间中是一个懒惰的操作
Yes,i think put the Extension methods in own company namespce is best practices. put it in System namespace is a lazy operation