asp.net mvc 之旅 —— 第五站 从源码中分析asp.net mvc 中的TempData

  在mvc的controller中,我们知道有很多的临时变量存放数据,比如说viewData,viewBag,还有一个比较特殊的tempData,关于前两个或许大家都明白,

基本上是一个东西,就是各自的编程写法不一样,最终都会放到viewContext中,然后送到WebPage中,如果你要证明的话,可以看下下面的代码。

        /// <summary>Gets the dynamic view data dictionary.</summary>
        <returns>The dynamic view data dictionary.</returns>
        [Dynamic]
        public dynamic ViewBag
        {
            [return: Dynamic]
            get
            {
                if (this._dynamicViewDataDictionary == null)
                {
                    this._dynamicViewDataDictionary = new DynamicViewDataDictionary(() => this.ViewData);
                }
                return this._dynamicViewDataDictionary;
            }
        }

        Gets or sets the dictionary for view data.The dictionary for the view data.</returns>
        public ViewDataDictionary ViewData
        {
            this._viewDataDictionary == )
                {
                    this._viewDataDictionary = new ViewDataDictionary();
                }
                ._viewDataDictionary;
            }
            setthis._viewDataDictionary = value;
            }
        }

从上面的代码中可以看到,其实ViewBag就是获取ViewData的数据,对不对。。。

 

一:TempData

    至于这个东西怎么用,大家貌似都记得是可访问一次后即刻消失,好像貌似也就这样了,当然不知道有没有人对tempdata的底层代码进行研究呢???

看一下它的底层到底是怎么来实现的。

 

1. TempData源代码

    首先我们看一下TempData的类型是TempDataDictionary,可以看到这个类型肯定是实现了IDictionary接口的自定义字典,

         TempDataDictionary TempData
        {
            this.ControllerContext != null && .ControllerContext.IsChildAction)
                {
                    .ControllerContext.ParentActionViewContext.TempData;
                }
                this._tempDataDictionary == this._tempDataDictionary = new TempDataDictionary();
                }
                ._tempDataDictionary;
            }
            this._tempDataDictionary = value;
            }
        }

从上面代码可以看到,tempdate默认是new了一个TempDataDictionary类,这个类中很好玩的地方在于这里有一个load方法,这个load方法就是获取真

正的provider,比如下面这样:

        Loads the specified controller context by using the specified data provider.<param name="controllerContext">The controller context.</param>
        <param name="tempDataProvider">The temporary data provider.</param>
        public void Load(ControllerContext controllerContext,ITempDataProvider tempDataProvider)
        {
            IDictionary<string,object> dictionary = tempDataProvider.LoadTempData(controllerContext);
            this._data = ((dictionary != null) ? new Dictionary<object>(dictionary,StringComparer.OrdinalIgnoreCase) : object>(StringComparer.OrdinalIgnoreCase));
            this._initialKeys = new HashSet<string>(._data.Keys,StringComparer.OrdinalIgnoreCase);
            ._retainedKeys.Clear();
        }

这个load方法就是非常重要的,这里的参数ITempDataProvider就是我们在BeginExecute方法赋值的,继续往下看,不要着急哦。。。

 

2. BeginExecute

   我们知道,mvc框架其实是截获了mvcroutehandler来进行截获url的请求,继而将后续的处理就由mvc框架来接管,最终会执行到Controller类下面的

BeginExecute,如果你不信,我可以开心加愉快的给你上代码,比如下面这样:

        protected virtual IAsyncResult BeginExecute(RequestContext requestContext,AsyncCallback callback,1)">object state)
        {
            Action action2 = ;
            .DisableAsyncSupport)
            {
                if (action2 == )
                {
                    action2 = delegate {
                        .Execute(requestContext);
                    };
                }
                Action action = action2;
                 AsyncResultWrapper.BeginSynchronous(callback,state,action,_executeTag);
            }
            if (requestContext == )
            {
                throw new ArgumentNullException("requestContext");
            }
            base.VerifyExecuteCalledOnce();
            .Initialize(requestContext);
            BeginInvokeDelegate<Controller> beginDelegate = (asyncCallback,callbackState,controller) => controller.BeginExecuteCore(asyncCallback,callbackState);
            EndInvokeVoidDelegate<Controller> endDelegate = delegate (IAsyncResult asyncResult,Controller controller) {
                controller.EndExecuteCore(asyncResult);
            };
            return AsyncResultWrapper.Begin<Controller>(callback,beginDelegate,endDelegate,1)">this,_executeTag,-1,1)">);
        }

上面这段代码中,你一定要看清楚上面标红的地方,这里我们看到了,其实这里是一个异步的beginxxx,endxxx的操作,问题就是在这里,首先我们从

beginInvoke说起。

 

<1> beginDelegate

       这个异步操作中,我们可以看到,其实执行的是一个controller.BeginExecuteCore(asyncCallback,callbackState) 方法,对吧,然后我们可以

感兴趣的看一下这个方法干了什么?

        virtual IAsyncResult BeginExecuteCore(AsyncCallback callback,1)"> state)
        {
            IAsyncResult result;
            this.PossiblyLoadTempData();
            try
            {
                Action action2 = ;
                string actionName = GetActionName(.RouteData);
                IActionInvoker invoker = .ActionInvoker;
                IAsyncActionInvoker invoker = invoker as IAsyncActionInvoker;
                if (invoker != )
                {
                    BeginInvokeDelegate<ExecuteCoreState> beginDelegate = (asyncCallback,asyncState,innerState) => innerState.AsyncInvoker.BeginInvokeAction(innerState.Controller.ControllerContext,innerState.ActionName,asyncCallback,asyncState);
                    EndInvokeVoidDelegate<ExecuteCoreState> endDelegate =  (IAsyncResult asyncResult,ExecuteCoreState innerState) {
                        if (!innerState.AsyncInvoker.EndInvokeAction(asyncResult))
                        {
                            innerState.Controller.HandleUnknownAction(innerState.ActionName);
                        }
                    };
                    ExecuteCoreState invokeState =  ExecuteCoreState {
                        Controller = ,AsyncInvoker = invoker,ActionName = actionName
                    };
                    return AsyncResultWrapper.Begin<ExecuteCoreState>(callback,invokeState,_executeCoreTag,1)">);
                }
                if (!invoker.InvokeAction(.ControllerContext,actionName))
                        {
                            .HandleUnknownAction(actionName);
                        }
                    };
                }
                Action action = action2;
                result =catch.PossiblySaveTempData();
                throw;
            }
             result;
        }

从上面的代码中,你应该看到了有一个 this.PossiblyLoadTempData()方法,看这个名字我们大概就可以猜得到这个方法和tempdate肯定有莫大的关系。

说时迟那时快,我们可以看下这个方法到底干了什么。。。在一系列跟踪之后,我们最后会到这个代码里面去了,如下所示:

        internal void PossiblyLoadTempData()
        {
            .ControllerContext.IsChildAction)
            {
                base.TempData.Load(base.ControllerContext,this.TempDataProvider);
            }
        }

 

请大家看清了,这里我们调用了刚才文章开头出说到的Tempdata.Load方法,那么问题来了,这里的TempDataProvider到底是怎么来的。我们继续来看代码:

         ITempDataProvider TempDataProvider
        {
            this._tempDataProvider == this._tempDataProvider = this.CreateTempDataProvider();
                }
                ._tempDataProvider;
            }
            this._tempDataProvider = value;
            }
        }

 

看到没有,然后TempDataProvider然来是调用了CreateTempDataProvider方法来实现的,下一步我们来看一下CreateTempDataProvider到底干了什么。

        virtual ITempDataProvider CreateTempDataProvider()
        {
            ITempDataProviderFactory service = this.Resolver.GetService<ITempDataProviderFactory>();
            if (service !=  service.CreateInstance();
            }
            return (this.Resolver.GetService<ITempDataProvider>() ??  SessionStateTempDataProvider());
        }

从上面这个代码,我们应该就明白了,然来我们的tempdata默认是由SessionStateTempDataProvider来提供的,好了,接下来我们就可以继续看看

SessionStateTempDataProvider大概实现的业务逻辑。

  class SessionStateTempDataProvider : ITempDataProvider
    {
        const string TempDataSessionStateKey = __ControllerTempData;
        
        virtual IDictionary< LoadTempData(ControllerContext controllerContext)
        {
            HttpSessionStateBase session = controllerContext.HttpContext.Session;
            if (session != )
            {
                Dictionary<object> dictionary = session["] as Dictionary<if (dictionary != )
                {
                    session.Remove();
                     dictionary;
                }
            }
            (StringComparer.OrdinalIgnoreCase);
        }
        
        virtual void SaveTempData(ControllerContext controllerContext,IDictionary< values)
        {
            if (controllerContext == controllerContext);
            }
            HttpSessionStateBase session =bool flag = (values != null) && (values.Count > 0);
            if (session == if (flag)
                {
                     InvalidOperationException(MvcResources.SessionStateTempDataProvider_SessionStateDisabled);
                }
            }
            else  (flag)
            {
                session["] = values;
            }
            if (session["] != )
            {
                session.Remove();
            }
        }
    }

可以看到,SessionStateTempDataProvider 是实现了ITempDataProvider接口,里面有两个方法LoadTempData 和SaveTempData方法,而

LoadTempData方法的逻辑很奇葩,你可以仔细观察一下哦,如果 if (session != null)满足就清空字典的数据,否则就不清除,这个逻辑大概就向

你展示了为什么数据只能被读取一次,下次读取的时候,就走了这个if(session!=null)给清空了,你怎么可能再读取session中的数据呢。。。这个

就是为什么tempdata只能被读取一次的真相,是不是很好玩。

 

<2> EndExecuteCore

    有人可能会问了,第二个方法SaveTempData是什么时候执行的,当然就是EndExecuteCore里面了,比如你看:

        protected virtual void EndExecuteCore(IAsyncResult asyncResult)
        {
            
            {
                AsyncResultWrapper.End(asyncResult,1)">finally
            {
                .PossiblySaveTempData();
            }
        }

可以看到它的默认实现是session,当然你也可以实现一个自定义的provider,比如用cache来存放这个临时数据,或者是redis,mongodb等等。。。

当然还有更多有趣的东西等待你发掘哦~~~

 

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


引言 本文从Linux小白的视角, 在CentOS 7.x服务器上搭建一个Nginx-Powered AspNet Core Web准生产应用。 在开始之前,我们还是重温一下部署原理,正如你所常见的.Net Core 部署图: 在Linux上部署.Net Core App最好的方式是在Linux机器
引言: 多线程编程/异步编程非常复杂,有很多概念和工具需要去学习,贴心的.NET提供Task线程包装类和await/async异步编程语法糖简化了异步编程方式。 相信很多开发者都看到如下异步编程实践原则: 遵守以上冷冰冰的②③条的原则,可保证异步程序按照预期状态正常运作;我们在各大编程论坛常看到违背
一. 宏观概念 ASP.NET Core Middleware是在应用程序处理管道pipeline中用于处理请求和操作响应的组件。 每个组件是pipeline 中的一环。 自行决定是否将请求传递给下一个组件 在处理管道的下个组件执行之前和之后执行业务逻辑 二. 特性和行为 ASP.NET Core处
背景 在.Net和C#中运行异步代码相当简单,因为我们有时候需要取消正在进行的异步操作,通过本文,可以掌握 通过CancellationToken取消任务(包括non-cancellable任务)。 Task&#160;表示无返回值的异步操作, 泛型版本Task&lt;TResult&gt;表示有返
HTTP基本认证 在HTTP中,HTTP基本认证(Basic Authentication)是一种允许网页浏览器或其他客户端程序以(用户名:口令) 请求资源的身份验证方式,不要求cookie,session identifier、login page等标记或载体。 - 所有浏览器据支持HTTP基本认
1.Linq 执行多列排序 OrderBy的意义是按照指定顺序排序,连续两次OrderBy,后面一个有可能会打乱前面一个的排序顺序,可能与预期不符。 要实现sql中的order by word,name类似效果; LINQ 有ThenBy可以紧接使用, ThenBy记住原本排序的值,然后再排其他值,
ASP.NET Core 核心特性:开源、跨平台、高性能是其决战JAVA的必胜法宝,最引人关注的跨平台特性 到底是怎么实现? &#xA; 本文分Unix、Windows剖析跨平台内幕,读完让你大呼过瘾。
前导 Asynchronous programming Model(APM)异步编程模型以BeginMethod(...) 和 EndMethod(...)结对出现。 IAsyncResult BeginGetResponse(AsyncCallback callback, object state
引言 最近在公司开发了一个项目,项目部署架构图如下: 思路 如图中文本所述,公司大数据集群不允许直接访问外网,需要一个网关服务器代理请求,本处服务器A就是边缘代理服务器的作用。 通常技术人员最快捷的思路是在服务器A上部署IISʺpplication Request Routing Module组件
作为一枚后端程序狗,项目实践常遇到定时任务的工作,最容易想到的的思路就是利用Windows计划任务/wndows service程序/Crontab程序等主机方法在主机上部署定时任务程序/脚本。 但是很多时候,若使用的是共享主机或者受控主机,这些主机不允许你私自安装exe程序、Windows服务程序
引言 熟悉TPL Dataflow博文的朋友可能记得这是个单体程序,使用TPL Dataflow 处理工作流任务, 在使用Docker部署的过程中, 有一个问题一直无法回避: 在单体程序部署的瞬间(服务不可用)会有少量流量无法处理;更糟糕的情况下,迭代部署的这个版本有问题,上线后无法运作, 更多的流
合格的web后端程序员,除搬砖技能,还必须会给各种web服务器配置Https,本文结合ASP.NET Core部署模型聊一聊启用Https的方式。 温故知新 目前常见的Http请求明文传输,请求可能被篡改,访问的站点可能被伪造。 HTTPS是HTTP加上TLS/SSL协议构建的可进行加密传输、身份认
长话短说 前文《解剖HttpClientFactory,自由扩展HttpMessageHandler》主要讲如何为HttpClientFactory自定义HttpMessageHandler组件, 现在来完成课后的小作业: 将重点日志字段显示到Nlog的LayoutRenderer上。 本文实现一个
引言问题 作为资深老鸟,有事没事,出去面试;找准差距、定位价值。 面试必谈哈希, Q1:什么是哈希? Q2:哈希为什么快? Q3:你是怎么理解哈希算法利用空间换取时间的? Q4:你是怎么解决哈希冲突的? Q5:你有实际用写过哈希算法吗? 知识储备 哈希(也叫散列)是一种查找算法(可用于插入),哈希算
前言 如题,有感于博客园最近多次翻车,感觉像胡子眉毛一把抓, 定位不了生产环境的问题。 抛开流程问题,思考在生产环境中如何做故障排除,&#160;发现博客园里面这方面的文章比较少。 .Net 本身是提供了sos.dll工具帮助我们在生产中故障排除,通过提供有关内部公共语言运行时(CLR)环境的信息,
.NET程序是基于.NET Framework、.NET Core、Mono、【.NET实现】开发和运行的 ,定义以上【.NET实现】的标准规范称为.NET Standard .NET Standard .NET标准是一组API集合,由上层三种【.NET实现】的Basic Class Library
长话短说 上个月公司上线了一个物联网数据科学项目,我主要负责前端接受物联网事件,并提供 参数下载。 webapp 部署在Azure云上,参数使用Azure SQL Server存储。 最近从灰度测试转向全量部署之后,日志时常收到: SQL Session超限报错。 排查 我在Azure上使用的是 S
临近年关,搜狗,360浏览器出现页面无法成功跳转,同域Cookie丢失? 也许是服务端 SameSite惹的祸。&#xA;本文揭示由于Chrome低版本内核不识别 SameSite= None, 引发的单点登录故障。
本文聊一聊TraceID的作用和一般组成,衍生出ASP. NETCore 单体和分布式程序中 TraceId 的使用方式
通过给 HttpClint请求的日志增加 TraceId,解锁自定义扩展 HttpClientFacroty 的姿势