今日起,文章系列标题名正式更名为.Net MVC4 被坑心得了!
今日修改了之前几个用ashx或aspx写的接口,其实用mvc写,直接返回JsonResult也是没什么区别的。但是既然微软推出了webapi,就尝尝味道吧。
只要去尝,就一定要被坑一坑。
首先是Request变掉了,变成了HttpRequestMessage类型,没见过的玩儿。但马上发现,Request的QueryString米有了,Form米有了,File米有了,啥都米有了,连IP都获取不了了。疼痛难忍。看来这货已经不是原始的Request了,被层层包装了。既然Request变了,Response想来也变了。试一下,很好,Response消失了。其实,整个HttpContext基本都不存在了。
怎么办呢,网上查了资料,发现可以这样:
var SrcRequest = (HttpContextWrapper)Request.Properties["MS_HttpContext"]).Request;
来获取原来的Request。不过感觉怪怪的,完美主义在作怪么。应该还有更简单的方法吧。
试试老方法:
var SrcRequest = HttpContext.Current.Request;
好,可以用,这样还好点。
接着是路由的问题。了解Controller/id 或者 Controller?id=id会路由到 Get(int id)。这已经没啥问题了,但是如果需要多参数呢?试了下,可以直接写在get方法的参数列表里,只是,如果缺少了某个参数,会返回一个错误的json数据(已经将返回设置为json格式)。这点让我很不理解,不是403或者404,也不是500,而是正常返回数据,只是返回了一串与我需要的json结构完全不同的结构的错误数据类似:
{"Message":"未找到与请求 URI“http://xxxx”匹配的 HTTP 资源。","MessageDetail":"在控制器“abc”上找不到与该请求匹配的操作。"}
很疼的。另外就是如果对于一些可以省略的参数怎么办呢。使用string或者int?就可以了么? 答案是否定的。使用了可null的类型,依然阻止不了mvc报错。那么试试[Optional]特性吧,在不是必须的字段上加上这个特性,跑起来,这次报错不一样了,虽然也是报错:
{"Message":"请求无效。","MessageDetail":"对于“xxxx”中方法“result Get(Int32, Int32, Int32)”的参数“yyy”,参数字典包含无效项。字典包含一个类型“System.Reflection.Missing”的值,但参数需要的是类型“System.Int32”的值。"}
上述,将int改成int?情况一样。
好吧,换个方法试试:
public CommentListResult Get(int id, int pindex = 1, int psize = 20)
这次终于行了…… 一个小坑填完了。接着下面的坑吧
对于post方式,问题又来了。使用[FromBody]特性,只能有一个参数,否则会报错(暂时不明白,可能是body就是指请求的全部Content吧),返回500。那么,如果不用[FromBody],全部排开,调用会如何呢?很好,返回404。又试了很多方法,总是不行。至此,我已经觉得wcf的Restful十分美妙了,webapi比起直接写controller差太多了。不过不能泄气,还是继续来吧。考虑有个方法是肯定可行的,就是不接收任何参数,然后通过原始的Request.Form来接收。但是,这样怎么看都不爽。试试其他方法。考虑会不会跟wcf一样,已经把传来的参数封装成了一个类,考虑把Request打包成一个类,然后传递。
因为只剩一个参数了,终于不报404了,也能返回。试一下,如果使用json或者xml格式传,可以传入正确值,但是用from传,传入的数据所有字段都是null……WCF正是用了Json或者xml的Content-Type来传递,才没有遇到这种问题。当然,我也曾经因为wcf的这个限制而郁闷过,使用mvc本以为会好点(事实上普通controller确实好很多,就算这个让人郁闷的webapi,其实也是比wcf要灵活一些的)。于是又一次难受起来。
恰巧看到一篇文章,写使用webapi遇到js请求跨域问题的解决方案。作者在使用了n多方案未果后,最后还是放弃了webapi,直接使用普通controller。由此有感,webapi还是有很多为考虑周全的东西。微软但凡成熟靠谱的东西,大都是收费的,但是mvc是开源的,源码拿来随便你玩不是微软喜欢干的事儿。正因为.net的mvc一直未真正成熟起来。微软从来兼容性做的都很好,但是在mvc我们发现,每一次更新和升级,都与之前的版本不兼容。折页说明mvc一直在发展和摸索。在mvc4中第一次露面的webapi,其成熟度又如何能。只有使用过才知道。
言归正传,最后还是使用HttpContext.Current.Request来获取Form的内容,然后做各种操作了。
至此,上面的get方法,为了避免传错参数而触发mvc返回默认的json错误,最好也改成这种方式。
于是,webapi的controller用着,跟普通controller和WebForm又木有任何区别了……