为什么一些HtmlHelper方法实现为扩展方法

Question

我目前正在创建一些自定义帮助程序类，类似于ASP.NET MVC的标准HtmlHelper。当我查看HtmlHelper的实现时，我注意到大多数/所有HTML生成方法（例如ActionLink()，BeginForm()，TextBox()等）都是不直接在HtmlHelper类中实现，而是作为单独类中的扩展方法实现（例如在class LinkExtensions中）。

除了更好的源代码组织外，在实现扩展方法而不是普通方法等方法时是否有任何优势？

在创建自己的帮助程序类时，我是否也应该遵循该模式？

更新：当我写道我想创建自己的帮助器类时，我的意思是扩展现有的HtmlHelper类。相反，我为我的视图创建了一个自定义基类（从ViewPage派生），我想在其中添加一个类似于ViewPage的Html和Url帮助类的辅助类。

Answer 1

我假设可能是因为框架设计指南提及（4.1）：

  

避免在与用于常见编程任务的类型相同的命名空间中为高级方案设计类型。

以及稍后的（5.6）关于扩展方法：

  

不要将扩展方法放在与扩展类型相同的命名空间中，除非它是用于向接口添加方法或用于依赖关系管理。

Phil Haack自己在同一页面上提到他们将“更高级”的功能放在一个单独的命名空间中，以免“污染”扩展类型的API。

我同意实际上更有用的方法（ActionLink等）不太容易被发现，但它们都是使用HtmlHelper（GenerateLink等）的核心API实现的，这是主命名空间的一部分。

如果您打算遵循官方设计指南并且在您的具​​体情况下有意义，我认为您应该遵循这种模式。

Answer 2

原因是：我们希望为您提供选择退出任何内置HTML帮助程序的功能，以防您喜欢自己编写或使用其他第三方帮助程序。如果它们不是特殊命名空间中的扩展方法，那么您将无法忽略它们。

Answer 3

我倾向于通过核心类来遵循该模式，然后根据需要为每个类添加扩展类。

关于优势......除了将实际类本身与扩展名分开之外，我不知道任何事情。