HtmlHelper扩展的动力学

问题描述

| 在键入“ this”类型后，我习惯于智能感知提供的扩展方法。但是，当我使用HtmlHelper尝试此操作时，即使存在\'using \'语句，扩展方法也不会显示。为什么是这样？为了明确起见，我正在从常规.cs文件而不是.cshtml文件中进行此测试。没有充分的理由，我只是在使用MVC命名空间和语言来“查看它是如何变化的。”我仍然不知道为什么intellisense不能提取全部4000个扩展（我夸大了，但是有许多）。 谈到成千上万的扩展，为什么将这些辅助例程作为扩展方法提供？如果使用了典型的静态类，则剃刀签名示例可能是：

@EditorExtensions.EditorFor<T>(...)

似乎可行，并且《框架设计指南》指出很少应该使用扩展，并且最好： 仅针对接口类型。 仅适用于无法重新部署的类型 似乎没有任何扩展方法“准则”适用。这就是为什么我期望常规的静态类，并使用静态方法来填补这一问题。有什么根据？ 更新：非扩展帮助程序的示例代码（进一步讨论）

public static class MyHelper
{
    public static MvcHtmlString Go(HtmlHelper foo){
        foo.Raw(\"Hello\");
        return new MvcHtmlString(\"<p>What\'s up Doc</p>\");
    }
}

    

解决方法

不知道为什么IntelliSense没有为您显示

HtmlHelper

扩展方法。你确定你是三英镑吗？ 之所以将这些帮助程序实现为扩展方法，是因为它们通常需要访问与请求，模型等关联的各种状态。要实现此目标，同时还要使帮助程序可以进行单元测试，要实现这一目标要困难得多如果它们是作为静态方法实现的。