net core Webapi基础工程搭建(七)——小试AOP及常规测试

  • 时间:
  • 浏览:1
  • 来源:幸运快3_快3最新版_幸运快3最新版

前言

一天天我不在 乎 怎样过的,但觉得挺忙,事赶事不带停那种,让他感觉跟在流水线干活一样,忙活的事差不要 了就喘口气继续补充你这种 系列的内容,前面几篇基本上把原先常规的后端服务搭建差不要 了,上边的会一个劲根据当时人须要可能常规的测试内容来许多点完善更新。

拦截器

这里先不提AOP的内容,其觉得我当时人就让 的理解,AOP开发的思想假若,我们都 做的许多操作类似于身份验证,日志记录,异扎好捕等等有有哪些操作,都须要单独拎出来放那,谁用了加个头部标识就都须要了,剩余的交给代码来补救,另原先我们都 开发就只须要关心业务功能,而许多的许多都须要后会考虑,这假若框架的好处,别人封装集成好,就都须要省去很大的开发工作量。

好,刚开始了了说拦截器,觉得也是上边层,当时人感觉跟AOP的概念类似于,就塞进 这里写上了。

异常拦截器

在我们都 Api的工程目录下新建文件夹Filters用于存放拦截器,就让 我们都 新建ExceptionFilter你这种 异常的拦截器,用于记录工程抛异常并做对应回调补救。

代码如下,具体不不要 解释,可能觉得觉得你这种 没啥说的,假若注意异步调用的难题图片即可。

    public class ExceptionFilter
    {
        private readonly RequestDelegate _next;

        /// <summary>
        /// 
        /// </summary>
        /// <param name="next"></param>
        public ExceptionFilter(RequestDelegate next)
        {
            _next = next;
        }

        /// <summary>
        /// 
        /// </summary>
        /// <param name="context"></param>
        /// <returns></returns>
        public async Task Invoke(HttpContext context)
        {
            try
            {
                await _next(context);
            }
            catch (Exception ex) //存在异常
            {
                context.Response.StatusCode = 60

0;
                LogUtil.Error($"response exception:{ex.Message}");// {ex.StackTrace}
                await ResponseUtil.HandleExceptionAsync(60

0, "服务器错误");
            }
        }
    }

你这种 地方的ResponseUtil是单独在Util层创建的(公共类尽量扔到同原先工程类库下,就让 一键打包,各种复用)。

    public class ResponseUtil
    {
        /// <summary>
        /// 回调
        /// </summary>
        /// <param name="statusCode">html情况报告码</param>
        /// <param name="msg">消息</param>
        /// <returns></returns>
        public static Task HandleExceptionAsync(int statusCode, string msg)
        {
            var data = new { code = statusCode, msg = msg };
            string text = JsonConvert.SerializeObject(data);
            var response = AprilConfig.HttpCurrent.Response;
            if (string.IsNullOrEmpty(response.ContentType))
            {
                //跨域的就让

注意,不带header如此接取消调
                response.Headers.Add("Access-Control-Allow-Origin", "*");
                response.Headers.Add("Access-Control-Allow-Credentials", "true");
                //可能你这种

是json
                response.ContentType = "application/json;charset=utf-8";
                response.StatusCode = 60

;
                response.ContentLength = text.Length;
                return response.WriteAsync(text);
            }
            else
            {
                return response.WriteAsync(text);
            }
        }
    }

就让 我们都 依然要在Startup中注册我们都 你这种 上边层。

        public void Configure(IApplicationBuilder app, IHostingEnvironment env)
        {
            app.UseMiddleware<ExceptionFilter>();
            …
        }

另原先我们都 在全局可能出现异常的就让 ,都须要统一捕获到难题图片,假若做记录,当然在测试环境下注意,可能你这种 错误帮助页打开的就让 ,那上边的拦截器将毫无乱用。

测试结果



另原先可能岂一定会哪个地方如此做异常捕获,全局最终一定会原先坚持问题导向的抓住假若告诉你,好处是可能懒那就所有地方一定会写了,难题图片是许多异常即使捕获假若不须要告知用户假若须要做记录(比如文件上传下载的任务管理器中断异常类似于的),许多你这种 假若为了保险起见而一定会为了省事。

身份验证拦截器

接下来我们都 继续创建原先AuthFilter,目的是做身份验证的判断,可能没通过就没必要再进入具体的控制器了。

    public class AuthFilter
    {
        private readonly RequestDelegate _next;

        public AuthFilter(RequestDelegate next)
        {
            _next = next;
        }

        public Task Invoke(HttpContext context)
        {
            if (context.Request.Method == "OPTIONS")
            {
                return _next(context);
            }
            var headers = context.Request.Headers;
            //检查头文件与非

有jwt token
            if (!headers.ContainsKey("Authorization"))
            {
                string path = context.Request.Path.Value;
                if (!AprilConfig.AllowUrl.Contains(path) && path.IndexOf("swagger") < 0)
                {
                    //这里做下相关的身份校验
                    return ResponseUtil.HandleExceptionAsync(401, "请登录");
                    
                    //判断与非

有权限查看(在身份验证后判断对应的权限,你这种

土办法

后续再写)
                    return ResponseUtil.HandleExceptionAsync(-2, "无权访问");

                }
            }
            return _next(context);
        }
    }

同样我们都 须要在Startup注册使用上边层。

        public void Configure(IApplicationBuilder app, IHostingEnvironment env)
        {
            app.UseMiddleware<ExceptionFilter>();
            app.UseMiddleware<AuthFilter>();
            …
        }

测试



假若访问我们都 的Swagger,效果就很明显了。

小结

你这种 篇主要假若引入上边层的使用,当时人认为有哪些AOP开发OOP开发全部因人而异,没必要为了追求新技术而去整体大功能改造,新技术觉得使用起来方便,一定会很好的前景,假若对于企业来讲,稳定是最重要的,后会为了1%的性能速度而去冒60 %甚至更高的风险,假若我还是要说一句,net core到目前为止可能历过原先大版本的更新,觉得3.0如此正式发布,假若原先个版本的更新就让 ,稳定性可能很ok了,许多该吃螃蟹都都须要动手了

下一篇,继续引入AOP的开发,主要用的第三方的组件AspectCore,将针对接口调用的就让 做许多常规操作。


补充 2019-07-31

今天在做调试的就让 发现原先难题图片,现状如下



发现你这种 难题图片我的第一反应是,字符编码,假若看完我回调的就让 明显可能设置了ContentType,许多你这种 应该一定会错误的是导致 ,假若多次刷新的测试结果是偶尔正常,怪异的情况报告一个劲伴随着bug,于是比对了正确的回调信息和错误的回调信息(这里是通过chrome浏览器调试假若获取的回调信息,具体调试土办法 后续前端介绍,当然基本上都知道)。



另原先一看发现了难题图片所在,许多你这种 地方决定不再自主去设置Length了。