我目前正在创建一些自定义的辅助类，类似于ASP.NET MVC的标准HtmlHelper实现的一些方法的HtmlHelper。当我看着HtmlHelper实施，我注意到大部分/所有的HTML生成方法（如ActionLink()，BeginForm()，TextBox()，等）不直接HtmlHelper类内部实现，而是作为单独的类扩展方法（例如在class LinkExtensions）。为什么作为扩展方法
除了，是否有任何优点实现这样的方法作为扩展方法，而不是正常的方法时？
在创建我自己的帮助类时，我是否也应遵循该模式？
更新：当我写我想创建自己的帮助类时，我的意思是扩展现有的HtmlHelper类。相反，我为我的视图创建了一个自定义的基类（从ViewPage派生），我想添加一个类似于ViewPage的Html和Url辅助类的辅助类。
的原因是：我们希望为您提供选择退出的任何能力内置的情况下，你最好写自己或使用其他一些第三方的助手，而不是HTML佣工。如果它们不是特殊命名空间中的扩展方法，那么您将无法忽略它们。
我倾向于遵循该模式，通过核心类，然后在需要的每个扩展类。
关于优点...我不知道除了将实际的类本身与其扩展分开之外，没有其他任何东西。
我想这可能是因为框架设计指南提到（4.1）：
避免在同一个命名空间用于常见编程任务类型设计的高级场景类型。
，后来（5.6）有关扩展方法：
不要把扩展方法在相同的命名空间扩展类型，除非它是添加方法接口或依赖管理。
Phil Haack本人在同一页面上提到他们在一个单独的命名空间中放置了“更高级”的funcionality，以免“污染”扩展类型的API。
我同意实际更有用的方法（ActionLink等）不易发现，但它们都是使用HtmlHelper的核心API（GenerateLink等）实现的，它是主命名空间的一部分。
如果您打算按照官方的设计准则，它是有道理的在您的具体情况，我想你应该坚持这种模式。
ISBN-10：0321545613 ISBN-13：978-0321545619 – 2010-01-14 12:54:41
因此，不需要以相同的方式构建自己的助手类？ – M4N 2010-01-14 16:08:00
实际上，扩展方法是您可以编写HTML帮助程序的唯一方法。 – 2010-01-15 02:14:35
我不想扩展HtmlHelper！我已经用更多的细节更新了这个问题。 – M4N 2010-01-16 21:59:04