每当我必须在会话中存储任何内容时,我就会习惯通过这样的方式尽量减少访问会话的次数:
private List<SearchResult> searchResults;
private List<JobSearchResult> SearchResults
{
get
{
return searchResults ?? (searchResults = Session["SearchResults"] as List<SearchResult>);
}
set
{
searchResults = value;
Session["SearchResults"] = value;
}
}
我的理由是,如果在回发过程中多次使用该对象,则必须不经常从Session中检索该对象。但是,我完全不知道这在性能方面是否真的有帮助,或者实际上只是浪费时间,甚至可能是一个坏主意。有没有人知道如何将计算成本高昂的不断拉出会话的对象与上述方法进行比较?或者,如果有任何最佳做法?
答案 0 :(得分:3)
取决于您使用的会话存储类型(有关详细信息,请参阅:here)。
如果您正在使用InProc存储,那么除非您经常访问该对象,否则性能差异可能很小。然而,本地副本并没有真正伤害任何一种方式。
答案 1 :(得分:1)
它肯定取决于你的存储单元,但它在任何一种情况下都是一个很好的方法,因为如果存储不是InProc它会阻止你进行DeSerialization ...即使在InProc的情况下它也阻止了Boxing \ UnBoxing ...所以我的投票赞成你的方法。
答案 2 :(得分:1)
我认为你的做法没有错。唯一的缺点是,当您的私有字段初始化后,当您(或其他人的)代码的其他部分代码更改会话值时,您的包装器属性仍将返回旧值。换句话说,除了第一次之外,无法保证您的财产实际上正在返回会话值。
至于性能,我认为在InProc的情况下几乎没有增益。可能类似于任何其他字典与变量存储。但是,当您使用其他会话存储模式时,它可能会有所不同。 如果你真的想知道你可以分析你的应用程序并找出答案;)你甚至可以尝试一些简单的跟踪写入和一些循环会话读/写之间的事情。
以下是关于会话存储内部的阅读: http://www.codeproject.com/KB/session/ASPNETSessionInternals.aspx
答案 3 :(得分:-2)
取决于要存储的数据大小,带宽(互联网或LAN),应用规模。如果数据大小很小,带宽足够好(LAN),规模在全球范围内(如Whitehouse.gov),我们应该将它存储在客户端(作为表单隐藏参数)。在其他情况下(数据量非常大,带宽很小,规模很小(只有3-4人将使用该应用程序),然后我们可以将它存储在服务器端(会话)。还有很多其他在这个决策选择中考虑它们的因素。 另外,我不建议您在会话对象中仅使用一个字段。在会话中创建类似Dictionary(HashMap in Java)的东西,并将其用作存储,用户应该传递此Dictionary的键来获取此数据。需要提供用户在多个选项卡中打开您的网站的能力。
URL示例,访问所需搜索:
http://www.mysite.com/SearchResult.aspx?search_result=d38e8df908097d46d287f64e67ea6e1a