知知网站推荐,wordpress主题市场,邢台网站建设讯息,工信部网站域名查询【框架内幕】| 作者 / Edison Zhou这是恰童鞋骚年的第196篇原创文章上一篇我们了解了AspNetCore.Mini这个项目的背景及项目结构和流程#xff0c;这一篇我们继续解析几个核心对象。本文整理自A大#xff08;蒋金楠#xff09;的主题分享#xff0c;点击本文底部“阅读原文”… 【框架内幕】| 作者 / Edison Zhou这是恰童鞋骚年的第196篇原创文章上一篇我们了解了AspNetCore.Mini这个项目的背景及项目结构和流程这一篇我们继续解析几个核心对象。本文整理自A大蒋金楠的主题分享点击本文底部“阅读原文”可以观看A大的该主题视频分享。1基于HttpListener的WebServer刚刚在WebHost中注入了Server并启动了Server。那么这个Server长啥样呢我们知道在ASP.NET Core中封装了Kestrel和IIS两个Server供我们使用那么它们肯定有一个抽象层这里是接口定义了他们共有的行为这里我们也写一个IServerpublic interface IServer
{Task RunAsync(RequestDelegate handler);
}
IServer接口行为很简单就是约定一个启动的方法RunAsync接受参数是中间件本质就是一个请求处理的委托。有了IServer接口就可以基于IServer封装基于不同平台的WebServer了这里基于HttpListener实现了一个HttpListenerServer如下HttpListener简化了Http协议的监听仅需通过字符串的方法提供监听的地址和端口号以及虚拟路径就可以开始监听请求public class HttpListenerServer : IServer
{private readonly HttpListener _httpListener;private readonly string[] _urls;public HttpListenerServer(params string[] urls){_httpListener new HttpListener();// 绑定默认监听地址默认端口为5000_urls urls.Any() ? urls : new string[] { http://localhost:5000/ };}public async Task RunAsync(RequestDelegate handler){Array.ForEach(_urls, url _httpListener.Prefixes.Add(url));if (!_httpListener.IsListening){// 启动HttpListener_httpListener.Start();}Console.WriteLine([Info]: Server started and is listening on: {0}, string.Join(;, _urls));while (true){// 等待传入的请求该方法将阻塞进程这里使用了await直到收到请求var listenerContext await _httpListener.GetContextAsync();// 打印状态行: 请求方法, URL, 协议版本Console.WriteLine({0} {1} HTTP/{2}, listenerContext.Request.HttpMethod, listenerContext.Request.RawUrl, listenerContext.Request.ProtocolVersion);// 获取抽象封装后的HttpListenerFeaturevar feature new HttpListenerFeature(listenerContext);// 获取封装后的Feature集合var features new FeatureCollection().SetIHttpRequestFeature(feature).SetIHttpResponseFeature(feature);// 创建HttpContextvar httpContext new HttpContext(features);Console.WriteLine([Info]: Server process one HTTP request start.);// 开始依次执行中间件await handler(httpContext);Console.WriteLine([Info]: Server process one HTTP request end.);// 关闭响应listenerContext.Response.Close();}}
}/// summary
/// IWebHostBuilder扩展使用基于HttpListener的Server
/// /summary
public static partial class Extensions
{public static IWebHostBuilder UseHttpListener(this IWebHostBuilder builder, params string[] urls) builder.UseServer(new HttpListenerServer(urls));
}
有了Server也有了中间件我们要进行处理的上下文在哪里熟悉ASP.NET请求处理的童鞋都知道我们会操作一个叫做HttpContext的东西它包裹了一个HttpRequest和一个HttpResponse我们要进行的处理操作就是拿到HttpRequest里面的各种参数进行处理然后将返回的结果包裹或调用HttpResponse的某些方法进行响应返回。在ASP.NET Core Mini中也不例外我们会创建一个HttpContext然后将这个HttpContext传递给注册的中间件各个中间件也可以拿到这个HttpContext去做具体的处理了。但是不同的Server和单一的HttpContext之间需要如何适配呢因为我们可以注册多样的Server可以是IIS也可以是Kestrel还可以是这里的HttpListenerServer。这时候我们又可以提取一个抽象层了如上图所示底层是具体的基于不同平台技术的Server上层是HttpContext共享上下文中间层是一个抽象层它是基于不同Server抽象出来的接口本质是不同Server的适配器下面就是这个IFeature的定义public interface IHttpRequestFeature
{Uri Url { get; }NameValueCollection Headers { get; }Stream Body { get; }
}public interface IHttpResponseFeature
{int StatusCode { get; set; }NameValueCollection Headers { get; }Stream Body { get; }
}
这里不再解释下面来看看HttpListener的适配的实现public class HttpListenerFeature : IHttpRequestFeature, IHttpResponseFeature
{private readonly HttpListenerContext _context;public HttpListenerFeature(HttpListenerContext context) _context context;Uri IHttpRequestFeature.Url _context.Request.Url;NameValueCollection IHttpRequestFeature.Headers _context.Request.Headers;NameValueCollection IHttpResponseFeature.Headers _context.Response.Headers;Stream IHttpRequestFeature.Body _context.Request.InputStream;Stream IHttpResponseFeature.Body _context.Response.OutputStream;int IHttpResponseFeature.StatusCode{get { return _context.Response.StatusCode; }set { _context.Response.StatusCode value; }}
}
可以看出这是一个典型的适配器模式的应用通过一个抽象层接口为不同Server提供HttpRequest和HttpResponse对象的核心属性。2Middleware与ApplicationBuilder在启动项目中定义了三个中间件如下所示public static RequestDelegate FooMiddleware(RequestDelegate next)async context
{await context.Response.WriteAsync(Foo);await next(context);
};public static RequestDelegate BarMiddleware(RequestDelegate next)async context
{await context.Response.WriteAsync(Bar);await next(context);
};public static RequestDelegate BazMiddleware(RequestDelegate next)context context.Response.WriteAsync(Baz);
可以看到每个中间件的作用都很简单就是向响应流中输出一个字符串。其中Foo和Bar两个中间件在输出之后还会调用下一个中间件进行处理而Baz不会调用下一个中间件进行处理因此Baz在注册顺序上排在了最后这也解释了我们为何在ASP.NET Core中进行中间件的注册时注册的顺序比较讲究因为这会影响到后面的执行顺序。刚刚在进行WebHost的创建时调用了WebHostBuilder的Configure方法进行中间件的注册而这个Configure方法的输入参数是一个IApplicationBuilder的委托public interface IApplicationBuilder
{IApplicationBuilder Use(FuncRequestDelegate, RequestDelegate middleware);RequestDelegate Build();
}
可能直接看这个接口定义不是太明白下面来看看ApplicationBuilder的实现public class ApplicationBuilder : IApplicationBuilder
{private readonly ListFuncRequestDelegate, RequestDelegate _middlewares new ListFuncRequestDelegate, RequestDelegate();/// summary/// 构建请求处理管道/// /summary/// returnsRequestDelegate/returnspublic RequestDelegate Build(){_middlewares.Reverse(); // 倒置注册中间件集合的顺序return httpContext {// 注册默认中间件 返回404响应RequestDelegate next _ {_.Response.StatusCode 404;return Task.CompletedTask;};// 构建中间件处理管道foreach (var middleware in _middlewares){next middleware(next);}return next(httpContext);};}/// summary/// 注册中间件/// /summary/// param namemiddleware中间件/param/// returnsApplicationBuilder/returnspublic IApplicationBuilder Use(FuncRequestDelegate, RequestDelegate middleware){_middlewares.Add(middleware);return this;}
}
其中Use方法的作用就是接受中间件进行注册Build方法的作用就是构建由注册中间件组成的请求处理管道而Server加上这个由中间件组成的请求处理管道便是ASP.NET Core的核心内容。因此我们可以说ASP.NET Core Pipeline Server Middlewares。此外我们还可以将多个Middleware构建成一个单一的“HttpHandler”那么整个ASP.NET Core框架将具有更加简单的表达Pipeline Server HttpHandler因此这里的Build方法中做了以下几件事情1倒置注册中间件集合的顺序_middlewares.Reverse();
为什么要倒置顺序呢不是说执行顺序要跟注册顺序保持一致么别急且看后面的代码。2注册默认中间件return httpContext
{// 注册默认中间件 返回404响应RequestDelegate next _ {_.Response.StatusCode 404;return Task.CompletedTask;};......
}
这里默认中间件是返回404在如果没有手动注册任何中间件的情况下生效。3构建一个中间件处理管道 HttpHandlerpublic RequestDelegate Build()
{......return httpContext {......// 构建中间件处理管道foreach (var middleware in _middlewares){next middleware(next);}return next(httpContext);};
}
在通过Use方法注册多个中间件到middlewares集合中后会在这里通过一个遍历组成一个单一的middleware在这里表示为一个RequestDelegate对象如下图所示。对于middleware它在这里是一个FuncRequestDeletegate, RequestDelegate对象它的输入和输出都是RequestDelegate。对于管道的中的某一个middleware来说由后续middleware组成的管道体现为一个RequestDelegate对象由于当前middleware在完成了自身的请求处理任务之后往往需要将请求分发给后续middleware进行处理所以它需要将由后续中间件构成的RequestDelegate作为输入。当代表中间件的委托对象执行之后我们希望的是将当前中间件“纳入”这个管道那么新的管道体现的RequestDelegate自然成为了输出结果。因此这里也就解释了为什么要在第一步中进行middleware的顺序的倒置否则无法以注册的顺序构成一个单一的middleware下图是示例代码中的所有middleware构成的一个单一的RequestDelegate经过层层包裹以达到依次执行各个middleware的效果。需要注意的就是在BazMiddleware中没有调用下一个中间件因此404中间件便不会得到触发处理的机会。下图是最后的执行结果3小结经过蒋金楠老师的讲解以及自己的学习对这个Mini版的ASP.NET Core框架有了一个初步的理解正如蒋老师所说ASP.NET Core的核心就在于由一个服务器和若干中间件构成的管道了解了这一点就对ASP.NET Core的核心本质有了大概印象。当然这个Mini版的ASP.NET Core只是模拟了ASP.NET Core的冰山一角还有许多的特性都没有比如基于Starup来注册中间件依赖注入框架配置系统预定义中间件等等等等但是对于广大ASP.NET Core学习者来说是个绝佳的入门是进阶学习ASP.NET Core源码的基石读物最后感谢大内老A的分享最后让我们一起期待A大的《ASP.NET Core框架揭秘》早日出版4参考资料蒋金楠《200行代码7个对象—让你了解ASP.NET Core框架的本质》蒋金楠《Inside ASP.NET Core Framework》Edison Zhouhttps://github.com/EdisonChou/AspNetCore.Mini????点击阅读原文观看A大分享
