下一代Asp.net开发规范OWIN(1)—— OWIN产生的背景以及简单介绍

随着VS2013的发布,微软在Asp.Net中引入了很多新的特性,比如使用新的权限验证模块Identity, 使用Async来提高Web服务器的吞吐量和效率等。其中一个不得不提的是OWIN和Katana. OWIN的全称是Open Web Interface For .Net, OWIN是.Net开源社区借鉴Ruby而制定的.Net Web开发架构,有着非常简单的规范定义,同时极度降低了模块间耦合。OWIN并不是一个具体的实现,而只是一个规范,用来指导如何构建一个符合OWIN标准的Web生态环境。微软引入并推广OWIN,同时依照OWIN规范,实现了Katana。

可以这么说,OWIN将会使Asp.net焕发第二春。下面,就让我们一步一步走近OWIN和Katana,一睹芳容。

阅读目录:

一. 回顾Asp.net的发展历史

二. 解决问题的思路

三. OWIN介绍

四,OWIN前景以及预测

一, 回顾Asp.net的发展历史

不知不觉,Asp.net已经伴随我们了10多个年头,渐渐步入中年。面对日新月异的Web开发变革,Asp.net已经显得有些力不从心。为什么会出现这种情况,让我们来回顾一下Asp.net的发展历史:

Asp阶段

最初开发Web,使用的是Asp, 这是一种嵌入在页面中的脚本语言。Asp的优势是简单,上手快,但是随着开发的日益复杂和Web程序的不断庞大,Asp这种逻辑代码和页面Html混在一起的开发方式已经不能够适应了。

Asp.net Web Form阶段

由于Asp的短板,升级Asp,打造一个新的Web开发平台已经是必然的事情了。猜想微软可能想让Winform上的开发者方便地迁移到Web开发上来,于是打造了一个开发过程和Winform及其类似的开发方式,这就是Asp.Net.

Asp.net Web Form在当时无疑是先进的,但是随着时间的推移,它的一些问题也暴露出来:
Asp.net中大部分的核心类都包含在System.Web.dll中,而System.Web.dll是包含在.Net Framework中的,这就意味着如果要发布一个新版本的Asp.net必须伴随着新的.Net Framework一起发布,这导致了Asp.net更新频率降低。另外,System.Web.dll是和IIS耦合的,使得Asp.net程序无法迁移到其它服务器上。

积极的改变

新的Asp.net MVC改变了过去的缺点,它是作为独立于.Net Framework发布的。所以MVC的版本变化,是无需受制于.Net Framework. 开发MVC的项目组就可以自主的快速开发和发布新的版本的MVC.
更进一步,在开发和发布Web API的时候,甚至都没有用到任何包含在System.Web.dll中的类型,这意味着:

  • Web API完全是无外部依赖的,它通过Nuget快速的发布和更新。
  • 不依赖于System.Web.dll, 也就意味着不依赖于IIS的服务,所以Web API是可以运行在其它宿主进程中的, 比如控制台程序,windows service等。

未来:更加灵活的框架

通过解构Asp.net开发中的一个一个框架组件,微软就能够更加快速的迭代和通过Nuget发布新的版本,添加新的增强功能。
未来更加灵活的框架就是我们可以随意根据项目需要,组合这些组件,然后运行在支持的Host上。

二,解决问题的思路

在引入OWIN之前,我们来对Web请求到响应的过程进行抽象:
一个Web请求的全过程是一个简单的输入和输出, 输入是request包含的头信息、cookie、数据等信息,输出是最后的Html. 这就好像是放进去面粉,最后出来的是做好的馒头。但是从面粉变成馒头却要经历很多工序,这一道一道的工序,就组成了整个流程。非常类似于装饰者模式,每一个装饰者对象都遵循同样的接口,这样我们就可以将不同的装饰者拼接起来。

下图是借鉴的python中的WSGI规范(Python Web Server Gateway Interface), 和下面将讲到的OWIN基本类似. Request经过一层层的洋葱皮,最后输出。这一层一层的洋葱皮就是我们的符合OWIN规范的组件。

pylons_as_onion 

三,OWIN介绍

OWIN就是按照上面思路和目标制定的一个规范,不包含任何具体实现。其目的是在web服务器和应用程序之间隔离出一个抽象层,使它们之间解耦。
OWIN设计的2个目标:  简单,以及尽量少的依赖其它的框架类型。
这样就能够:

  • 新的组件能够非常简单的开发和应用
  • 程序能够简便地在host和OS上迁移

OWIN核心定义

OWIN将web应用中的request, response, session, cookie等所有相关信息都简化成下面的字典。本质上来说,这个字典就包含了一个web请求的所有上下文信息。
一个符合OWIN的web服务器,需要将请求信息包装成下面的字典类型,传递到下一层中。而下一层的组件或者应用程序,所要做的就是读取,修改这个字典的数据。最后,Web服务器得到这个层层处理过的字典,然后输出网页到客户端

IDictionary<string, object>

下面是具体的定义

Key Name

Value Description

"owin.RequestBody"

A Stream with the request body, if any. Stream.Null MAY be used as a placeholder if there is no request body. See Request Body.

"owin.RequestHeaders"

An IDictionary<string, string[]><string, string[]=""> of request headers. See Headers.

"owin.RequestMethod"

A string containing the HTTP request method of the request (e.g., "GET", "POST").

"owin.RequestPath"

A string containing the request path. The path MUST be relative to the "root" of the application delegate; see Paths.

"owin.RequestPathBase"

A string containing the portion of the request path corresponding to the "root" of the application delegate; see Paths.

"owin.RequestProtocol"

A string containing the protocol name and version (e.g. "HTTP/1.0" or "HTTP/1.1").

"owin.RequestQueryString"

A string containing the query string component of the HTTP request URI, without the leading “?” (e.g., "foo=bar&baz=quux"). The value may be an empty string.

"owin.RequestScheme"

A string containing the URI scheme used for the request (e.g., "http", "https"); see URI Scheme.

另外一个核心是application delegate,这是所有运行在OWIN协议下的组件都需要遵循的接口

Func<IDictionary<string, object>, Task>;

这样定义的原因是: 

  • 由于依赖少,写一个component非常容易和简单
  • 异步设计使得程序的运行效率更高,特别是在遇到一些I/O密集的操作时
  • application delegate 是可执行的最小单元,OWIN components可以非常容易的互相连接组成一个Http处理管道

四,OWIN前景以及预测

由于使用OWIN规范,使得Asp.net进化的更加快,对于新的东西也能够快速响应。

OWIN的发展,将来会有越来越多的基于OWIN的应用框架出现(中间件),也将会由更多的OwinHost出现,其一就是微软先发制人Katana,它能够运行于Windows中,独立于IIS为支持OWIN协议的框架提供宿主支持;而另外一款则是率先支持OWIN协议的运行于Linux以及FreeBSD的Jexus Web Server(需要Jexus 5.6 以上版本).

尽管Asp.Net年纪很大,但是现在也越来越潮了,小伙子们有的东西,它也有了,而且以后对时尚的敏感度会更加敏锐。而它所具有的稳定,成熟气质,却是其它小伙子难以具备的。这是.Net最好的时代,不是吗?

你可能感兴趣的:(asp.net)