最佳实践:C#扩展方法命名空间和提升扩展方法

我们将它们都放在各自的名称空间中 Company.Common.Extensions . 那样的话,如果你有我们的任何扩展方法,你都有。另外,至少在我的店里,我们不必担心我们的开发人员不知道扩展方法。我有相反的担心,扩展方法过载!:)

这里的问题不是名称空间的命名,而是缺少文档和对开发人员的教育。

将它们放在任何有意义的名称空间中,编写一篇wiki文章,记录所有扩展方法,然后向开发人员发送一封电子邮件,其中包含指向wiki文章的链接。

这不是名称空间问题,而是通信问题。

如果这些方法有用,您需要将其传达给开发人员,反过来,根据他们的反馈采取行动(具有适当的判断水平)。

将任何内容放入系统名称空间都会导致以后的灾难和混乱。您唯一想做的就是将功能“后端口”到较旧的框架中,然后您可能不应该自己做,而应该使用LinqBridge之类的工具来做。

要小心将所有扩展放在一个名称空间中的想法,除非它们真的一起广泛有用。一些开发者可能会发现,如果他们通过intellisense受到所有东西和厨房水槽的轰炸,他们可能会失去树木。

将名称空间保留为公司名称通常是明智的,以避免混淆。

正如JP所说,我经常在称为Extensions的子文件夹中看到扩展方法。希望当您声明使用my.company.web.utils时,名称空间实际上是Pascal大小写的?

假定您使用VisualStudio,一种方法是创建自定义类模板(或修改默认模板),以便开发人员在创建新类文件时,自动在命名空间中使用using语句。见C ustomize Visual Studio 2005 Templates for Coding Productivity .

是的,我认为将扩展方法放在自己的公司名称中PCE是最佳实践。将其放在系统命名空间中是一个惰性操作

我喜欢ReSharper解决这个问题的方式。

ReSharper发现任何可用的扩展方法,即使没有相应的 使用范围 . 万一 如果不存在,Intellisense还会显示扩展所在的命名空间,从而明确扩展的来源 指示选择它将添加 使用

当然,只包括当前项目可以访问的名称空间,即直接或间接引用的名称空间。

下面是一个示例,说明如果有两种扩展方法,Intellisense可能会显示什么。第一个来自我们已经包含的名称空间。第二个来自一个名称空间,我们还没有(尚未)包括它。

• AddMvc
• AddEntityFrameworkSqlServer (Microsoft.Extensions.DependencyInjection)

我们将所有内容放在同一名称空间和类中,但是我们使用分部类来保持它们的组织。

例如:

ExtensionMethods-String.cs

ExtensionMethods-DataObject.cs

…等都有分部类。。。

您可以通过在全局命名空间中放置扩展方法来实现所需的功能。这就是我所做的,然后它们就可以在不需要任何帮助的情况下使用了 using 声明。