仓酷云

标题: ASP.NET网页设计痴心意外:ASP.NET WebAPI RC 居然不撑持最经常使用的json传参仓酷云 [打印本页]

作者: 小女巫    时间: 2015-1-18 11:18
标题: ASP.NET网页设计痴心意外:ASP.NET WebAPI RC 居然不撑持最经常使用的json传参仓酷云
前天傍晚我发表了《net网页编程的跨平台就是一句谎言。》,原本就是周末闲来无事,发表一篇略带争议性的博文让大家都来吵吵架,发表自己的看法,根本就没想着谁把谁打倒,一个行业或者是技术阵营是无法用短期口水仗打到对手的。勇士断腕(WCFWebAPI),为的是ASP.NETWebAPI的横空出生,再加上它的开放(开源),因而对之发生了一点点痴情,并写下了HttpClient+ASP.NETWebAPI,WCF以外的另外一个选择。当时,ASP.NETWebAPI还处于beta阶段,俗语说女年夜十八变,天然对ASP.NETWebAPIRC发生了向往。。。
ASP.NETWebAPIRC闪亮退场以后,还未一睹庐山真脸孔,就有人陆连续续反应之前博文中的示例代码在ASP.NETWebAPIRC版中没法一般运转。其间,我们有一个利用了ASP.NETWebAPI的项目晋级至ASP.NETWebAPIRC以后也碰到了一样的成绩,经由过程HttpClien将json格局的数据post给服务器以后,服务端把持器中对应的Action却收不到数据,毛病信息为:"TheparametersdictionarycontainsanullentryforparameterstartIdofnon-nullabletypeSystem.Int32formethod..."。
入手下手觉得是HttpClient的成绩,之前的代码是经由过程Json.NET将必要传送的数据序列化为json字符串的,代码以下:
  1. varrequestJson=JsonConvert.SerializeObject(new{startId=1,itemcount=3});HttpContenthttpContent=newStringContent(requestJson);httpContent.Headers.ContentType=newMediaTypeHeaderValue("application/json");varhttpClient=newHttpClient();varresponseJson=httpClient.PostAsync("http://localhost:9000/api/demo/sitelist",httpContent).Result.Content.ReadAsStringAsync().Result;
复制代码
而ASP.NETWebAPIRC的改善之一是内置对Json.NET的撑持,以是postjson格局的数据更复杂了,下面的代码能够改成:
  1. varresponseJson=newHttpClient().PostAsJsonAsync("http://test.cnblogs.cc/api/demo/sitelist",new{startId=1,itemcount=3}).Result.Content.ReadAsStringAsync().Result;
复制代码
可是HttpClient的代码变动以后,成绩仍然存在,用Fiddler检察了一下post已往的数据,原汁原味正宗的json数据,看来成绩出在服务器端。
这时候,有人反应经由过程jQuery的$.ajax提交json数据,服务端也收不到。不必想了,成绩一定出在服务端。看看示例程序的服务端代码:
  1. publicclassDemoController:ApiController{publicIList<Site>SiteList(intstartId,intitemcount){...returnresult;}}
复制代码
成绩应当出在RC版本中,ASP.NETWebAPI将吸收到的post数据传统给Action的处置体例产生了改动。起首能够一定的是,ASP.NETWebAPIRC不成能不撑持json参数。岂非要为此界说一个类(好比这里叫SiteListQuery),将今朝的参数都作为类的属性,代码以下:
  1. publicclassDemoController:ApiController{publicIList<Site>SiteList(SiteListQueryquery){...returnresult;}}publicclassSiteListQuery{publicintstartId{get;set;}publicintitemcount{get;set;}}
复制代码
假如真是如许,就必要界说良多如许的参数类,并且即便只要一个参数,也要界说一个类。假如真是如许,我宁肯不必ASP.NETWebAPI。
事先想到这里,就没有进一步往实验,心想既然不撑持经常使用的json传参体例,那就临时不必ASP.NETWebAPIRC,等正式版出来再看。
明天一名同事证明了切实其实必要界说一个专门的参数类,才干撑持json传参。
当同事告知我以后,那种爱恨交集的不是味道的感到就迸收回来了。怎样能如许计划,即便如许计划有它的事理,也不克不及保持对一般利用体例的兼容啊。优秀的兼容性是微软的发财之本,怎样在这里就被忽视呢?检察ASP.NETWebAPI的源代码,这部分也没有完全的测试代码。ASP.NET大概是微软的无意插柳,但如今柳成萌了,何不借重开展为丛林呢?舍不得丢下桌面,怎能创始将来?将ASP.NETWebStack开源,事实是由于它可有可无,仍是由于真正想经由过程社区的力气让它开展得更好?在如许的关头时代,微软是在拿本人的优势追逐他人的上风,仍是在拿本人的上风超出他人?
痴情的不是ASP.NETWebAPI,而是用更文雅的手艺更好的办理实践成绩;
不测的不是这个有点糟的计划,并且没有真正从开辟者的角度往思索。
(注:一挥而就,一吐为快,也是一种写博客的体例,写的不当的地方瞥见谅)
示例代码下载:CNBlogsWebApiRcDemo.rar
就安全性而言,net网页编程已经远远低于VB.NET,更无法与安全性著称的C#相比。
作者: 只想知道    时间: 2015-1-20 20:01
逐步缩小出错代码段的范围,最终确定错误代码的位置。
作者: 飘灵儿    时间: 2015-1-29 19:43
能产生和执行动态、交互式、高效率的站占服务器的应用程序。运用ASP可将VBscript、javascript等脚本语言嵌入到HTML中,便可快速完成网站的应用程序,无需编译,可在服务器端直接执行。容易编写。
作者: 蒙在股里    时间: 2015-2-4 13:55
在调试JSP代码时,如果程序出错,JSP服务器会返回出错信息,并在浏览器中显示。这时,由于JSP是先被转换成Servlet后再运行的,所以,浏览器中所显示的代码出错的行数并不是JSP源代码的行数。
作者: 仓酷云    时间: 2015-2-5 04:52
但是java靠开源打出的一片天地,特别是在微软的垄断下能打开今天的局面还是有它的生命力的。
作者: 小妖女    时间: 2015-2-11 04:01
ASP在执行的时候,是由IIS调用程序引擎,解释执行嵌在HTML中的ASP代码,最终将结果和原来的HTML一同送往客户端。
作者: 分手快乐    时间: 2015-2-28 15:35
ASP是把代码交给VBScript解释器或Jscript解释器来解释,当然速度没有编译过的程序快了。
作者: 再见西城    时间: 2015-3-4 18:15
同时也感谢博客园给我们这个平台,也感谢博客园的编辑们做成专题引来这么多高人指点。
作者: 精灵巫婆    时间: 2015-3-11 07:49
ASP.Net和ASP的最大区别在于编程思维的转换,而不仅仅在于功能的增强。ASP使用VBS/JS这样的脚本语言混合html来编程,而那些脚本语言属于弱类型、面向结构的编程语言,而非面向对象。
作者: 变相怪杰    时间: 2015-3-17 23:15
现在的ASP.net分为两个版本:1.1和2.0Asp.net1.1用VS2003(visualstudio2003)编程。Asp.net2.0用VS2005(visualstudio2005)编程。现在一般开发用的是VS2003。
作者: 老尸    时间: 2015-3-25 06:51
在一个项目中谁敢保证每天几千万甚至几亿条的数据不丢失?谁敢保证应用的高可靠性?有可以借签的项目吗?




欢迎光临 仓酷云 (http://ckuyun.com/) Powered by Discuz! X3.2