最佳實踐：C＃擴展方法命名空間和提升擴展方法

Question

我知道已經存在一個帖子 ，描述幾乎相同，但我認為我的有點不同。

我想知道的是如何在分配命名空間方面組織擴展方法。 目前 - 對於我們框架中的擴展方法 - 我使用以下命名空間模式

• MyCompany.Web.Utils

在里面我有擴展方法類。 這對我來說很好，但缺點是我們的軟件開發人員無法立即看到擴展器。 考慮我有一個StringExtender類的情況，它提供了一個非常方便的擴展方法“In” ，它擴展了String對象。 使用帶有上述命名空間的擴展方法，我們的程序員除非明確包含其命名空間，否則不會看到擴展方法。 相反，如果我將擴展方法放在System命名空間中，每個人都會立即看到它，但我讀到這是不好的做法 。

所以我的問題是你如何推廣你的開發人員使用的擴展方法。

Answer 1

我們將它們全部放在自己的命名空間Company.Common.Extensions 。 這樣，如果你有我們的任何擴展方法，你就擁有它們。 另外，至少在我的商店，我們不必擔心我們的開發人員不了解擴展方法。 我有相反的擔心，擴展方法超載！ :)

Answer 2

這里的問題不是命名空間的命名，而是缺乏開發人員的文檔和教育。

將它們放入任何有意義的命名空間中，寫一篇記錄所有擴展方法的wiki文章，然后向開發人員發送一封電子郵件，其中包含指向wiki文章的鏈接。

Answer 3

這不是名稱空間問題，而是通信問題。

如果這些方法很有用，您需要將其傳達給開發人員，並相反地根據他們的反饋行事（具有適當的判斷水平）。

將任何內容放入System命名空間是一個災難和混亂的方法。 您唯一想要這樣做的是將“后端”功能轉換為舊框架，然后您可能不應該自己動手，但應該使用像LinqBridge這樣的功能。

警惕將所有擴展都放入一個命名空間的願望，除非它們真的在一起廣泛使用。 一些開發商可能會發現，如果他們被所有東西和廚房水槽轟炸，那么樹木就會丟失。

將命名空間保留為公司名稱通常是明智的，以避免混淆。

Answer 4

@Juri-如果你考慮一下，這與開發人員知道.NET框架中存在類X的問題是一樣的。 溝通是所有團隊成員使用正確課程的關鍵，無論是擴展方法還是其他幫助者。

正如JP所說，我經常在某種稱為Extensions的子文件夾中看到擴展方法。 希望當你聲明使用my.company.web.utils時，命名空間實際上是Pascal套接字？

即使你把它們放在一個好地方，也沒有100％保證其他開發者會使用它們。

Answer 5

假設您使用Visual Studio，一種方法是創建自定義類模板（或修改默認模板），這樣無論何時開發人員創建新的類文件，它都會自動在您的命名空間中使用using語句。 請參閱C ustomize Visual Studio 2005模板以獲得編碼生產力 。

Answer 6

是的，我認為將擴展方法放在自己的公司名稱中是最佳實踐。 把它放在System命名空間是一個懶惰的操作

Answer 7

我是愚蠢的，懶惰的和簡約的，所以我把它們放在與它們擴展的類型相同的命名空間中。 通過這種方式，不需要額外的使用聲明，文檔或電子郵件（Winston）。

Answer 8

您可以通過將擴展方法放在全局命名空間中來實現所需的功能。 這就是我所做的，然后他們可以在不需要任何using聲明的情況下using 。

Answer 9

我們將所有內容放在同一個命名空間和類中，但是我們使用部分類來保持它們的有序性。

例如：

ExtensionMethods-String.cs

ExtensionMethods-DataObject.cs

ExtensionMethods-Debug.cs

......等等都有部分班級......

Answer 10

我喜歡ReSharper解決這個問題的方式。

ReSharper的發現任何可用的擴展方法，即使沒有相應的usings。 如果使用不存在，Intellisense還會顯示擴展所在的命名空間，明確擴展來自何處， 並指示選擇它將添加使用 。 （以下示例。）

當然，只包括當前項目可以訪問的名稱空間，即直接或間接引用的名稱空間。

以下是Intellisense在有兩種擴展方法時可能會顯示的示例。 第一個來自我們已經包含的命名空間。 第二個來自我們尚未包含的名稱空間。

• AddMvc
• AddEntityFrameworkSqlServer (Microsoft.Extensions.DependencyInjection)