为什么一些 HtmlHelper 方法被实现为扩展方法
我当前正在创建一些自定义帮助器类，类似于 ASP.NET MVC 的标准 HtmlHelper。当我查看 HtmlHelper 的实现时，我注意到大多数/所有 HTML 生成方法（例如 ActionLink()、BeginForm() >、TextBox() 等）不是直接在 HtmlHelper 类内部实现的，而是作为单独类中的扩展方法（例如在 class LinkExtensions 中）。
除了更好的源代码组织之外，实现扩展方法等方法而不是普通方法还有什么优势吗？
在创建我自己的帮助器类时，我也应该遵循该模式吗？
更新：当我写到我想创建自己的帮助器类时，我确实想扩展现有的 HtmlHelper 类。相反，我为视图创建了一个自定义基类（从 ViewPage 派生），并且我想添加一个类似于 ViewPage 的 Html 和 Url 帮助器类的附加帮助器类。
I'm currently creating some custom helper classes, similar to ASP.NET MVC's standard HtmlHelper. When I looked at the implementation of HtmlHelper, I noticed that most/all of the HTML generating methods (such as ActionLink(), BeginForm(), TextBox(), and so on) are not implemented directly inside the HtmlHelper class, but as extension methods in separate classes (e.g. in class LinkExtensions).
Apart from a nicer source-code organisation, is there any advantage when implementing such methods as extension methods instead of normal methods?
When creating my own helper classes, should I also follow that pattern?
Update: when I wrote that I wanted to create my own helper class, then I did mean to extend the existing HtmlHelper class. Instead I created a custom base class for my views (derived from ViewPage) and I want to add there an additional helper class similar to the Html and Url helper classes of ViewPage.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
原因是：我们希望为您提供选择退出任何内置 HTML 帮助程序的能力，以防您更愿意编写自己的帮助程序或使用其他第三方帮助程序。如果它们不是特殊命名空间中的扩展方法，您将无法忽略它们。
The reason is: we wanted to provide you with the ability to opt-out to any of the built-in HTML helpers in case you preferred to write your own or use some other 3rd party helpers instead. If they weren't extension methods in a special namespace, you wouldn't be able to ignore them.
我想可能是因为框架设计指南提到（4.1）：
以及稍后（5.6）关于扩展方法的内容：
Phil Haack 本人在同一页上提到，他们将“更高级”的功能放在单独的命名空间中，以免“污染”扩展类型的 API。
我同意实际上更有用的方法（
ActionLink等）不太容易被发现，但它们都是使用 HtmlHelper 的核心 API 实现的（GenerateLink等）。 ) 这是主命名空间的一部分。如果您打算遵循官方设计指南并且它在您的具体情况下有意义，我认为您应该遵循这种模式。
I suppose it might be because the Framework Design Guidelines mentions (4.1):
and later on (5.6) about extension methods:
Phil Haack himself mentions on the same page that they put "more advanced" funcionality in a separate namespace in order not to "pollute" the API of the extended type.
I agree that the methods that actually are more useful (
ActionLinkand so on) are less discoverable, but they are all implemented using the core API of HtmlHelper (GenerateLink, etc.) which is part of the main namespace.If you intend to follow the official design guidelines and it makes sense in your specific case, I think you should adhere to this pattern.
我倾向于遵循这种模式，通过核心类，然后在需要时为每个类提供扩展类。
关于优点......除了将实际类本身与其扩展分开之外，我不知道任何事情。
I tend to follow that pattern by having core classes, and then extension classes for each one where needed.
Regarding advantages... I'm not aware of anything apart from separating the actual classes themselves from their extensions.