ViewBag VS MVC中的ViewData性能差异？ [英] ViewBag vs ViewData performance difference in MVC?
问题描述
我知道的ViewData和ViewBag都使用相同的背衬的数据和既不是因为在大多数情况下，使用强类型的模型那样好。但是两者之间进行选择时是ViewBag的动态性比使用的ViewData慢？
I know that ViewData and ViewBag both use the same backing data and that neither are as good as using strongly typed models in most cases. However when choosing between the two is the dynamic nature of ViewBag slower than using ViewData?
推荐答案
好吧 - 我最初的回答基本上是说'不' - 时间有点调头
Okay - my initial answer basically said 'no' - time for a bit of a u-turn.
它的应的是'不'，在一个完美的动态的世界 - 但仔细检查后它会出现有要么是没有什么区别（占JIT魔法），或者它的可能是不断所谓稍微慢一些，虽然还不足以保证不使用它（我当然）。
It should be 'no' in a perfect dynamic world - but upon closer inspection it would appear that there will either be no difference (accounting for JIT magic) or it might be ever-so-slightly slower, although not enough to warrant not using it (I certainly am).
在理论上的如果正确实施的，则ViewBag最终将跑赢使用ViewData字典，因为前任pressions结合（例如 ViewBag.Foo ）是在不同的<一个很好的缓存href=\"http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.callsite.aspx\">CallSites编译器将生成（反映不读的方法或写入 ViewBag ，你就会明白我的意思）。
In theory if properly implemented, the ViewBag would ultimately outperform the use of the ViewData dictionary because the binding of the expressions (e.g. ViewBag.Foo) is very well cached across the different CallSites that the compiler will generate (reflect a method that does a read or write to the ViewBag and you'll see what I mean).
在DLR 有据可查的缓存层（如果有点难以理解一次你深入得到），但基本上是运行时会尽力'记住'，其中一个给定值实例一旦其绑定它 - 例如通过设置或获取陈述
The caching layers of the DLR are well documented (if a little difficult to understand once you get in depth) but basically the runtime does its best to 'remember' where a given value instance is once its bound it - for example via a Set or Get statement.
BUT 的缓存，它的使用和效果，完全是依赖于类/接口如的DynamicObject ，<一个href=\"http://msdn.microsoft.com/en-us/library/system.dynamic.idynamicmetaobjectprovider.aspx\">IDynamicMetaObjectProvider等等;还有的get / set方法前pression结合落脚点。
BUT The caching, its use and effectiveness, is entirely dependent upon the underlying implementations of classes/interfaces such as DynamicObject, IDynamicMetaObjectProvider etc; as well as the end-result of the Get/Set expression binding.
在MVC内部DynamicViewDataDictionary类的情况下 - 它最终结束了结合这一点：
In the case of the MVC internal DynamicViewDataDictionary class - it ultimately ends up binding to this:
public override bool TryGetMember(GetMemberBinder binder, out object result)
{
result = this.ViewData[binder.Name];
return true;
}
有关 VAR一个= ViewBag.Foo
和
public override bool TrySetMember(SetMemberBinder binder, object value)
{
this.ViewData[binder.Name] = value;
return true;
}
有关 ViewBag.Foo =酒吧;
在换句话说 - 语句被有效被改写到周围的字典索引包装
In other words - the statements are effectively being rewritten to wrappers around the dictionary indexer.
正因为如此，肯定没有办法，它可能比你自己做的更快。
Because of that, there's certainly no way it could be faster than doing it yourself.
是的ViewData 来养活了 ViewBag 的，而不是倒过来了，只好 ViewBag 然后得到落实，甚至用类似<一个href=\"http://msdn.microsoft.com/en-us/library/system.dynamic.expandoobject.aspx\"><$c$c>ExpandoObject,那么它可能是一个不同的故事 - 作为动态执行<一个href=\"http://msdn.microsoft.com/en-us/library/system.dynamic.expandoobject.aspx\"><$c$c>ExpandoObject更加智能和缓存规则它采用允许一些pretty爽运行的优化。
Were ViewData to feed off of ViewBag, instead of the other way around, and had ViewBag then been implemented with even something like ExpandoObject, then it might be a different story - as the dynamic implementation of ExpandoObject is much more intelligent and the caching rules it employs allow for some pretty cool runtime optimisations.
的（感谢肖恩·麦克莱恩的建议一名需要！）的
ViewBag将比ViewData的慢;但可能并不足以支持关注。
ViewBag will be slower than ViewData; but probably not enough to warrant concern.
这篇关于ViewBag VS MVC中的ViewData性能差异？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
