目前,我在实现接口的类中实现了 VaryByCustom 功能IOutputCacheVaryByCustom
public interface IOutputCacheVaryByCustom
{
string CacheKey { get; }
HttpContext Context { get; }
}
实现此接口的类有一些约定,类的名称将是“OutputCacheVaryBy_______”,其中空白是从页面上的 varyByCustom 属性传入的值。另一个约定是 Context 将通过构造函数注入来设置。
目前我基于一个枚举和一个类似于的 switch 语句
public override string GetVaryByCustomString(HttpContext context,
string varyByCustomTypeArg)
{
//for a POST request (postback) force to return back a non cached output
if (context.Request.RequestType.Equals("POST"))
{
return "post" + DateTime.Now.Ticks;
}
var varyByCustomType = EnumerationParser.Parse<VaryByCustomType?>
(varyByCustomTypeArg).GetValueOrDefault();
IOutputCacheVaryByCustom varyByCustom;
switch (varyByCustomType)
{
case VaryByCustomType.IsAuthenticated:
varyByCustom = new OutputCacheVaryByIsAuthenticated(context);
break;
case VaryByCustomType.Roles:
varyByCustom = new OutputCacheVaryByRoles(context);
break;
default:
throw new ArgumentOutOfRangeException("varyByCustomTypeArg");
}
return context.Request.Url.Scheme + varyByCustom.CacheKey;
}
因为我总是知道该类将是OutputCacheVaryBy + varyByCustomTypeArg
并且唯一的构造函数参数将是context
我意识到我可以绕过需要这个美化的 if else 块并且可以只用Activator
.
话虽如此,反射并不是我的强项,我知道Activator
与静态创建和其他生成对象的方式相比,它的速度要慢得多。有什么理由我应该坚持使用这个当前的代码,或者我应该使用Activator
或类似的方式来创建我的对象吗?
我看过博客http://www.smelser.net/blog/post/2010/03/05/When-Activator-is-just-to-slow.aspx但我不确定这将如何应用因为我在运行时使用类型而不是静态 T。