ASP.NET教程之ASP.NET Web API Selfhost宿主情况中管...
前几天同学问我学习方向的问题。有点想法，不知道对不对，怕误导同学，现在“开源一下”。注：括号内是我现在整理的时填加上的。媒介后面的几个篇幅对WebAPI中的路由和管道举行了复杂的先容并没有具体的往申明一些甚么，但是ASP.NETWebAPI这个框架因为宿主情况的分歧在分歧的宿主情况中管道中的完成机制和路由的处置体例有着很年夜的分歧，以是我会将对应分歧的宿主情况来分离的做出复杂的解说。
ASP.NETWebAPI路由、管道
ASP.NETWebAPI开篇先容示例
ASP.NETWebAPI路由工具先容
ASP.NETWebAPI管道模子
ASP.NETWebAPIselfhost宿主情况中管道、路由
ASP.NETWebAPIwebhost宿主情况中管道、路由
ASP.NETWebAPISelfHost宿主情况管道
起首我们先来看个表示图，也许的形貌了在SelfHost宿主情况中管道形状。
由于在WebHost宿主情况中ASP.NETWebAPI的管道哀求吸收和呼应的前往最初都是由ASP.NET来包揽的（下一篇中解说），而在SelfHost宿主情况中就苦逼了，没有那末复杂了。
我们依照中表示的来说解，起首在SelfHost宿主情况中的项目启动以后（固然项目要利用WebAPI框架的），会有一个HttpBinding工具（System.Web.Http.SelfHost.Channels），那这个HttpBinding范例的工具是干吗的呢？Httpbinding工具对应着一些个BindingElement工具，而这些BindingElement又各自天生对应的管道层监听器，如许就如中所示的那样，如今我们看一下以下的示例代码，看看HttpBinding究竟对应着哪些BindingElement工具。
示例代码1-1
publicclassHttpBinding:Binding,IBindingRuntimePreferences{publicHttpBinding(){this.Initialize();}privatevoidInitialize(){this._security=newHttpBindingSecurity();this._httpTransportBindingElement=newHttpTransportBindingElement();this._httpTransportBindingElement.ManualAddressing=true;this._httpsTransportBindingElement=newHttpsTransportBindingElement();this._httpsTransportBindingElement.ManualAddressing=true;this._httpMessageEncodingBindingElement=newHttpMessageEncodingBindingElement();}}在示例代码1-1中我们能够分明的看到在HttpBinding工具的机关函数平分其余对几种BindingElement举行了实例化赋值，我们只对个中的HttpTransportBindingElement和HttpMessageEncodingBindingElement举行解说也就是中所示的那样。
HttpTransportBindingElement工具的次要职责就是天生绝对应的管道监听器，这里对应的就是IChannelListener<TChannel>泛型范例了，而天生好对应的管道监听器以后，监听器以后会入手下手监听与之对应的管道层，与HttpTransportBindingElement工具和监听器对应的也就是TransprotChannel管道层了，它卖力哀求动静的吸收和呼应动静的发送。
HttpMessageEncodingBindingElement范例的工具所做操纵同HttpTransportBindingElement范例分歧，都是先要天生对应的管道监听器，在这里与之对应的就是HttpMessageEncodingChannelListener范例，在监听器天生好以后也会往监听对应的EncodingChannel管道层，而EncodingChannel管道层次要的感化就是将哀求信息封装为HttpMessage范例的动静工具，以后由HttpMessage动静对象进进ASP.NETWebAPI框架的管道体系中。
下面说的是在哀求未抵达ASP.NETWebAPI框架的管道体系中的时分在内部的一些处置和操纵，上面我们就要申明一下外部，在上篇的《ASP.NETWebAPI管道模子》篇幅中有示例代码演示过在SelfHost情况下管道的注册，我们这里看一下在SelfHost情况中WebAPI框架本身的管道体系里的工具的一些范例。
HttpSelfHostServer动静处置程序（完成类-管道头）System.Web.Http.SelfHost
publicsealedclassHttpSelfHostServer:HttpServer{publicHttpSelfHostServer(HttpSelfHostConfigurationconfiguration);publicHttpSelfHostServer(HttpSelfHostConfigurationconfiguration,HttpMessageHandlerdispatcher);publicTaskCloseAsync();protectedoverridevoidDispose(booldisposing);publicTaskOpenAsync();}能够看到HttpSelfHostServer范例承继自HttpServer，在上篇中我们也就提到过HttpServer是承继自DelegatingHandler笼统范例的动静处置程序基类，DelegatingHandler与HttpMessageHandler的分歧的地方就是多了个指向下一个处置程序的援用，固然了作为一个管道体系中第一个动静处置程序必需是要有指向下一个处置程序援用的这么一个标识，如许是公道的。我们再看HttpSelfHostServer范例的机关函数的参数范例。
HttpSelfHostConfiguration范例是承继自HttpConfiguration范例的，在上篇中我们也说过，HttpConfiguration中能够设置管道中的年夜多半信息，这个人人能够本人往看一下。在重载机关函数中有了第二个机关函数参数，HttpMessageHandler范例的参数，在默许利用HttpSelfHostServer的时分倘使不利用这个重载的机关函数，那末在HttpSelfHostServer实例化的之前先实例化之前，其基类HttpServer的机关函数入手下手实行，以是在看下HttpServer范例的机关函数的时分我们能够看到这里默许设置的HttpMessageHandler范例的参数究竟是甚么模样的。
publicHttpServer():this(newHttpConfiguration()){}publicHttpServer(HttpMessageHandlerdispatcher):this(newHttpConfiguration(),dispatcher){}publicHttpServer(HttpConfigurationconfiguration):this(configuration,newHttpRoutingDispatcher(configuration)){}publicHttpServer(HttpConfigurationconfiguration,HttpMessageHandlerdispatcher){this._initializationLock=newobject();if(configuration==null){throwSystem.Web.Http.Error.ArgumentNull("configuration");}if(dispatcher==null){throwSystem.Web.Http.Error.ArgumentNull("dispatcher");}this._dispatcher=dispatcher;this._configuration=configuration;}这里人人能够分明的看到是HttpRoutingDispatcher范例作为管道的最初一个处置程序的范例，关于这个范例和具体的信息，鄙人面的路由大节中会有申明。
ASP.NETWebAPISelfHost宿主情况路由
关于路由的其他常识这里就不说了，就是扼要的提一下在SelfHost中路由、管道的一些细节。
这里要具体申明的就是HttpRoutingDispatcher范例中的SendAsync()办法，看下源码中的完成如许更分明。
publicclassHttpRoutingDispatcher:HttpMessageHandler{//FieldsprivatereadonlyHttpConfiguration_configuration;privatereadonlyHttpMessageInvoker_defaultInvoker;//MethodspublicHttpRoutingDispatcher(HttpConfigurationconfiguration):this(configuration,newHttpControllerDispatcher(configuration)){}protectedoverrideTask<HttpResponseMessage>SendAsync(HttpRequestMessagerequest,CancellationTokencancellationToken){IHttpRouteDatarouteData;if(!request.Properties.TryGetValue<IHttpRouteData>(HttpPropertyKeys.HttpRouteDataKey,outrouteData)){routeData=this._configuration.Routes.GetRouteData(request);if(routeData==null){returnTaskHelpers.FromResult<HttpResponseMessage>(request.CreateErrorResponse(HttpStatusCode.NotFound,Error.Format(SRResources.ResourceNotFound,newobject[]{request.RequestUri}),SRResources.NoRouteData));}request.Properties.Add(HttpPropertyKeys.HttpRouteDataKey,routeData);}RemoveOptionalRoutingParameters(routeData.Values);HttpMessageInvokerinvoker=(routeData.Route.Handler==null)?this._defaultInvoker:newHttpMessageInvoker(routeData.Route.Handler,false);returninvoker.SendAsync(request,cancellationToken);}}我们先看一下HttpRoutingDispatcher范例中机关函数，能够看到在界说的机关函数前面紧接着又在实例基类的机关函数，而且第二个HttpMessageHandler范例的参数为HttpControllerDispatcher实例的工具，这个我们先记着就好了。
上面我们仍是回到HttpRoutingDispatcher范例的SendAsync()办法中，起首我们会看到从HttpRequestMessage工具实例的Properties属性汇合中猎取路由数据工具。
在SelfHost的情况下这是猎取不到的，为啥？由于下面和之前的篇幅中在管道的处置中没有提到过处置路由而且天生路由数据的。以是这个时分会依据HttpConfiguration中的HttpRouteCollection范例的属性Routes,Routes属性再依据SendAsync()办法的参数范例为HttpRequestMessage的request信息猎取路由数据工具IHttpRouteData。
在婚配乐成猎取到路由数据工具（IHttpRouteData）以后便会增加至HttpRequestMessage工具实例（request）的Properties属性汇合中。
之前关于路由的懂得，最初的实行的Handler都是后来界说在路由工具中的，而在实践情形中，我们注册路由的时分并没有，倘使这类情形就在如今发生，能够看到routeData.Route.Hander==null这个是建立的，以是实行的是我们先前说过的在机关函数中的HttpControllerDispatcher范例的实例的SendAsync()办法（实践傍边HttpControllerDispatcher范例被HttpMessageInvoker范例所封装）。
不过你如果学.net的话，你就不要选os了，这课比较底层的。你可以旁听数据库加上软件构件和中间件。（webservices和面向服务的课也应该听一听） 平台无关性是PHP的最大优点，但是在优点的背后，还是有一些小小的缺点的。如果在PHP中不使用ODBC，而用其自带的数据库函数（这样的效率要比使用ODBC高）来连接数据库的话，使用不同的数据库，PHP的函数名不能统一。这样，使得程序的移植变得有些麻烦。不过，作为目前应用最为广泛的一种后台语言，PHP的优点还是异常明显的。 ASP.net的速度是ASP不能比拟的。ASP.net是编译语言，所以，当第一次加载的时候，它会把所有的程序进行编译(其中包括worker进程，还有对语法进行编译，形成一个程序集)，当程序编译后，执行速度几乎为0。 同时也感谢博客园给我们这个平台，也感谢博客园的编辑们做成专题引来这么多高人指点。 可以看作是VC和Java的混合体吧，尽管MS自己讲C#内核中更多的象VC，但实际上我还是认为它和Java更象一些吧。首先它是面向对象的编程语言，而不是一种脚本，所以它具有面向对象编程语言的一切特性。 是目前ASP在UNIX/Linux上的应用可以说几乎为0）。所以平台的局限性和ASP自身的安全性限制了ASP的广泛应用。 市场决定一切，我个人从经历上觉得两者至少在很长时间内还是要共存下去，包括C和C++，至少从找工作就看得出来，总不可能大家都像所谓的时尚一样，追捧一门语言并应用它。 JSP/Servlet虽然在国内目前的应用并不广泛，但是其前途不可限量。
页:
[1]