"
上面的项目建好后,可以导出为项目模板.以后添加新项目选择模板即可.
webconfig需要添加处理程序映射.注意path "*." ,匹配 /user/info 这种不带扩展名的路径
<add name="AdministerHandler" path="*." verb="*" type="命名空间.AdministerHandlerFactory" resourceType="Unspecified" preCondition="integratedMode" />
对于静态文件,不需要走处理管道,使用系统的静态文件处理模块.不必配置
<add name="StaticFile" path="*" verb="*" modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule" resourceType="Either" requireAccess="Read">
配置了AdministerHandler "*." 映射后,请求没有指定文件名时,不再返回默认文档如index.html.
这个url调用的是test类的index方法
/test/index
这个url调用的是testns的index方法,api是testns类的命名空间.这个功能可以将API分类(文件夹)
/api/testns/index
基于asp.net提供的IHttpHandler接口,自定义的一个webapi框架,实现IHttpHandler接口完成处理请求,映射到处理类.较早就做出来了,今天整理了一下,独立成一个项目.
目的在于尽量减少使用和部署复杂度.只需要建一个类库项目,实现两个接口就能支持web请求了.
很早在做这个东西时参考了很多网上的博客,主要是要理解asp.net的管道处理逻辑.这个是在请求到来后,暴露的一系列方法,注册这些方法就能自定义处理过程.
当时做这个东西主要是因为自带的框架如webform,asp.net mvc,web api,虽然便利,但也有很多东西不必要的.为了精减,至少做一个类似一般处理程序的这种东西就行.
https://www.cnblogs.com/fish-li/ 这个博客的帮助最大,讲得最为清晰.
想起最早先使用perl做cgi时,就是处理程序了.总结一下,做一个能处理web请求的程序.要解决三个问题.监听,匹配,处理.
监听的问题交给IIS了.匹配和处理主要是通过IHttpHandler和IHttpHandlerFactory两个接口.这两个接口是asp.net框架提供的.事件顺序大概是第11个事件和第7个事件
匹配主要是分析请求url,将它映射到具体的处理类.实例化这个类并且调用方法就完成处理.这一系列的逻辑仍然是基于asp.net管道事件的.