爲什麼作爲擴展方法

我目前正在創建一些自定義的輔助類，類似於ASP.NET MVC的標準HtmlHelper實現的一些方法的HtmlHelper。當我看着HtmlHelper實施，我注意到大部分/所有的HTML生成方法（如ActionLink()，BeginForm()，TextBox()，等）不直接HtmlHelper類內部實現，而是作爲單獨的類擴展方法（例如在class LinkExtensions）。爲什麼作爲擴展方法

從一個更好的源代碼組織

除了，是否有任何優點實現這樣的方法作爲擴展方法，而不是正常的方法時？

在創建我自己的幫助類時，我是否也應遵循該模式？

更新：當我寫我想創建自己的幫助類時，我的意思是擴展現有的HtmlHelper類。相反，我爲我的視圖創建了一個自定義的基類（從ViewPage派生），我想添加一個類似於ViewPage的Html和Url輔助類的輔助類。

來源

2010-01-14 M4N

的原因是：我們希望爲您提供選擇退出的任何能力內置的情況下，你最好寫自己或使用其他一些第三方的助手，而不是HTML傭工。如果它們不是特殊命名空間中的擴展方法，那麼您將無法忽略它們。

來源

2010-01-14 15:24:22

因此，不需要以相同的方式構建自己的助手類？ – M4N 2010-01-14 16:08:00

實際上，擴展方法是您可以編寫HTML幫助程序的唯一方法。 – 2010-01-15 02:14:35

我不想擴展HtmlHelper！我已經用更多的細節更新了這個問題。 – M4N 2010-01-16 21:59:04

我傾向於遵循該模式，通過核心類，然後在需要的每個擴展類。

關於優點...我不知道除了將實際的類本身與其擴展分開之外，沒有其他任何東西。

來源

2010-01-14 12:46:26

我想這可能是因爲框架設計指南提到（4.1）：

避免在同一個命名空間用於常見編程任務類型設計的高級場景類型。

，後來（5.6）有關擴展方法：

不要把擴展方法在相同的命名空間擴展類型，除非它是添加方法接口或依賴管理。

Phil Haack本人在同一頁面上提到他們在一個單獨的命名空間中放置了「更高級」的funcionality，以免「污染」擴展類型的API。

我同意實際更有用的方法（ActionLink等）不易發現，但它們都是使用HtmlHelper的核心API（GenerateLink等）實現的，它是主命名空間的一部分。

如果您打算按照官方的設計準則，它是有道理的在您的具體情況，我想你應該堅持這種模式。

來源

2010-01-14 12:49:17 LorenzCK

ISBN-10：0321545613 ISBN-13：978-0321545619 – 2010-01-14 12:54:41

爲什麼作爲擴展方法

回答

相關問題