Owin学习笔记(一) Owin的前生今世

ASP.NET框架至今为止已经存在了数十年了,大量的网站使用ASP.NET框架进行开发。随着网站应用开发技术的进步,  许多网站应用开发框架有了新的流行趋势

  • 轻量化
  • 模块化
  • 可移植

ASP.NET框架在新的流行趋势下,显得非常臃肿,主要原因就是ASP.NET的基础是System.Web程序集,它里面集成了各种网站开发需要的组件,不管你需不需要,他都集成在当中,大量组件耦合在一起,很难分离开来。这与微软之前大而全的思想非常匹配,只要你使用我的ASP.NET框架,所有的网站开发都可以在一个框架中完成。

而且System.Web程序集是.NET Framework的一部分,这就导致他只能跟随.NET Framework的年度更新而更新,这与当前快速迭代的网站应用开发技术不太匹配。

最严重的是System.Web极度依赖IIS服务器,使得ASP.NET只能在Windows服务器上部署,在Linux, Mac等其他服务器上就没有办法施展拳脚。

ASP.NET MVC和ASP.NET Web Api

微软在发现这个问题之后,开始了自己的变革,微软希望将ASP.NET改造成一个可插拔组件集合,而非一个单独的框架。

微软首当其冲的就是将组件移出.NET框架发布。在随后推出的ASP.NET Mvc中微软进行了首次尝试,参考Ruby on Rail, 微软实现了自己的MVC框架,分离了前台页面和后台业务逻辑,并且ASP.NET Mvc是独立于.NET Framework进行发布,这极大的加快了这个框架的迭代速度。

随着网站应用开发技术的继续发展,大量后端的任务前移,静态页面 + Ajax动态填充内容成为流行,微软又推出了自己的轻量级Web服务框架ASP.NET Web Api。这个新生的框架是独立于System.Web程序集的。而且他还首次支持了Custom Host, 使得ASP.NET Web Api可以脱离IIS,在其他地方进行托管(命令行程序,Windows Service)。

Owin的诞生

微软受启于Ruby社区中的思想, 开始对Web服务器和Web框架组件进行解耦,创建了一系列的抽象接口,使Web框架组件不在依赖具体的服务器,而是依赖于这些新的接口,这样就解除了服务器与组件的耦合,所有实现接口的服务器程序,都可以作为组件的托管服务器。

所谓的Owin其实就是抽象接口的统称(The Open Web Interface for .NET)。

Owin的诞生使得Web组件更容易开发,更容易使用,而且对于使得ASP.NET的网站应用可以迁移到所有潜在的系统(Linux, Mac等)中。

Owin的2个核心元素

环境字典

IDictionary<string, object>

环境字典定义了兼容Owin的Web服务器需要在Http请求中读取的数据,以及在Http响应中需要更新或呈现的数据

例:需要从请求中读取的数据

Key Name

Value Description

“owin.RequestBody”

请求体内容

“owin.RequestHeader”

请求头部信息

“owin.RequestMethod”

Http请求的方法(Get,Post..)

“owin.RequestPath”

请求地址

“owin.RequestPathBase”

请求地址

“owin.RequestProtocol”

请求使用的协议

“owin.RequestQueryString”

请求Url中的参数

“owin.RequestSchema”

请求的Url Schema, http或者https

环境字典对应的应用委托字典

Func<IDictionary<string, object>, Task>

该字典中保存了对每个环境字典Key所做对应操作方法,这些方法的输入参数是环境字典Key, 然后返回一个Task

从实现的角度讲,Owin是一个标准,他的目标不是下一代Web开发框架,而是一个Web框架和Web服务器交互的标准

Katana

Katana是武士刀的意思,微软官方依据Owin标准实现的一组Owin组件,这些组件中集成了基础组件(托管程序和服务器)和一些功能组件(授权组件),同时也支持SignalR和ASP.NET Web Api

下面我们以一个Hello World程序为例

首先我们创建一个空的ASP.NET项目

Owin学习笔记(一) Owin的前生今世

下一步,我们安装Microsoft.Owin.Host.SystemWeb程序集,这个程序集提供了一个运行ASP.NET请求管道的Owin服务器

Install-Package Microsoft.Owin.Host.SystemWeb

安装完成之后, 添加Owin启动类,设置对所有的请求返回文本Hello World

public class Startup

{

public void Configuration(IAppBuilder app)

{

app.Run(context =>

{

context.Response.ContentType = "text/plain";

return context.Response.WriteAsync("Hello World!");

});

}

}

按F5运行之后之后,你会发现他还是使用了默认的IIS Express来运行程序,因为这里使用的兼容System.Web的服务器,默认就是用IIS托管。

切换服务器

然后我们来尝试一下,使用非IIS服务器托管这个Web应用

首先我们需要安装程序集OwinHost, OwinHost是Katana提供的使用HttpListener为基础的服务器,他同样实现了之前的环境字典标准

Install-Package OwinHost

安装完成之后,使用命令行运行OwinHost,启动完毕之后,打开浏览器输入localhost:5000(5000是默认端口), 你就能看到对应的内容。

Owin学习笔记(一) Owin的前生今世

Katana的架构

Katana从架构上来说分4层,由上到下一次是应用层,中间件层,服务器层,托管层,每一层都可以*选择使用的组件

Owin学习笔记(一) Owin的前生今世

托管层

Katana的托管层负责开启Web应用并维护该应用进程,有3种可选的实现

  • IIS/ASP.NET – 使用IIS托管
  • Custom Host – 自定义托管,Web应用可以托管在命令行或者Windows服务当中
  • OwinHost – Katana提供的托管

服务器层

服务器负责监听请求,发送响应。 当前Katana提供的服务器组件有2个

  • Owin.Host.SystemWeb
  • Owin.Host.HttpListener

中间件层

中间件层负责注入Owin组件管道中使用的组件,Web API, SignalR等都是在这里进行注入启用,这里也是最长扩展的一个部分,开发人员可以自己定义常用的中间件。所有的中间件都必须继承OwinMiddleware抽象类,后续我会写一些中间层扩展的例子

后记

Owin定义一系列规范,来解除服务器和应用之间的耦合,使的整个ASP.NET框架变得越来越轻量化,并提供了一定的可移植性,为后续微软研发ASPNETCore提供了基础,按照官网文档的说明ASPNETCore使用了Owin的规范,但是据先驱者透漏ASPNETCore已经和Owin没有关系了(有待考究),只是沿用了思想,ASPNETCore使用了新的Kestrel服务器,等于说是Owin基本被放弃了。但是如果对于不使用ASPNETCore开发的程序员,学习Owin还是对开发很有帮助的。

上一篇:PHP之static静态变量详解(一)


下一篇:USB Type-C 应用面临安全性考验,USB-IF 将推动新认证机制