然后我引用了Spark dll并在同一个Product视图文件夹下创建了Index.spark. Application_Start看起来像
protected void Application_Start()
{
RegisterRoutes(RouteTable.Routes);
ViewEngines.Engines.Clear();
ViewEngines.Engines.Add(new Spark.Web.Mvc.SparkViewFactory());
ViewEngines.Engines.Add(new WebFormViewEngine());
}
我的期望是,由于Spark引擎在默认WebFormViewEngine之前注册,当在Product控制器中浏览Index操作时,应该使用Spark引擎,并且WebFormViewEngine应该用于所有其他URL.
但是,测试表明,产品控制器的索引操作也使用WebFormViewEngine.
如果我注释了WebFormViewEnginer(代码中的最后一行)的注册,我可以看到,索引操作是由Spark引擎呈现的,其余的URL会产生错误(因为defualt引擎已经不见了),这证明我所有的火花码是正确的.
解决方法
在火花的情况下,视图应该具有.spark扩展名. WebFormViewEngine将响应.aspx或.ascx扩展名.当然,如上所述,您可以通过更改提供给各个视图引擎的ViewLocationFormat来覆盖任何一个.
更新：
我浏览了SparkViewFactory和WebFormViewEngine(或更具体地说,后者源自的VirtualPathProviderViewEngine)的源码,我可以告诉你为什么你看到这个奇怪的行为.
首先,ViewEngineCollection类中的Find方法类似于此(简化)：
foreach (IViewEngine engine in Items) {
// Query engine for cached view
}
foreach (IViewEngine engine in Items) {
// Query engine for uncached view
}
换句话说,它将始终尝试在任何引擎中查找缓存的视图,然后再使用未缓存的模式.
单个视图引擎实现这一点的方式是FindView方法的第二个重载,该方法使用一个名为useCache的bool参数.
然而,这里的所有东西都变得奇怪 – VirtualPathProviderViewEngine和SparkViewEngine对useCache参数的含义有非常不同的想法.这里有太多的代码来重新发布,但基本思路是：
>如果useCache为true,则SparkViewFactory将仅在缓存中查找.如果没有找到任何东西,它会自动返回“高速缓存未命中结果” – 即没有.另一方面,如果useCache为false,则不会在缓存中查找,它将跳过缓存检查步骤,并通过正常运动来解析并创建实际视图.
>另一方面,如果useCache为true,则VirtualPathProviderViewEngine会在缓存中查找,如果在缓存中没有找到该视图,则它会关闭并创建一个新的视图,并将其添加到缓存.
这两种方法都适用于ViewEngineCollection执行搜索的方式.
>在火花的情况下,它在视图引擎的第一次迭代中“错过”,而第二次“点击”,之后将该视图添加到缓存中.没问题.
>在VirtualPathProviderViewEngine的情况下,它在内部“错过”,但是在第一次迭代时返回“命中”,此时视图将被缓存.
所以你应该可以看到问题出在哪里. VirtualPathProviderViewEngine似乎优先于SparkViewEngine,因为前者总是成功执行第一次(缓存)迭代,但Spark仅在第二次(未缓存)迭代中成功.
在简单的英文中,Spark确实会先问出问题,但是回复：“不,我还没有这个看法,而不用缓存吧. WebForms被问到第二个,但自动说“我没有这个看法,但我去了,为你做了一个,这里是”.从那时起,WebFormViewEngine总是获得优先级,因为它具有缓存的视图,而Spark没有.
总结：Spark正在优先考虑,但是由于Spark对待useCache参数的方式有点奇怪,当Web Form引擎同时处于活动状态时,它会被灰尘遮住.任何一个WebForm都是过分的,或者Spark是懒惰的,这取决于你的观点.
