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#相比。

逐步缩小出错代码段的范围，最终确定错误代码的位置。

能产生和执行动态、交互式、高效率的站占服务器的应用程序。运用ASP可将VBscript、javascript等脚本语言嵌入到HTML中，便可快速完成网站的应用程序，无需编译，可在服务器端直接执行。容易编写。

在调试JSP代码时，如果程序出错，JSP服务器会返回出错信息，并在浏览器中显示。这时，由于JSP是先被转换成Servlet后再运行的，所以，浏览器中所显示的代码出错的行数并不是JSP源代码的行数。

仓酷云

但是java靠开源打出的一片天地，特别是在微软的垄断下能打开今天的局面还是有它的生命力的。

ASP在执行的时候，是由IIS调用程序引擎，解释执行嵌在HTML中的ASP代码，最终将结果和原来的HTML一同送往客户端。

ASP是把代码交给VBScript解释器或Jscript解释器来解释，当然速度没有编译过的程序快了。

同时也感谢博客园给我们这个平台，也感谢博客园的编辑们做成专题引来这么多高人指点。

ASP.Net和ASP的最大区别在于编程思维的转换，而不仅仅在于功能的增强。ASP使用VBS/JS这样的脚本语言混合html来编程，而那些脚本语言属于弱类型、面向结构的编程语言，而非面向对象。

现在的ASP.net分为两个版本：1.1和2.0Asp.net1.1用VS2003(visualstudio2003)编程。Asp.net2.0用VS2005(visualstudio2005)编程。现在一般开发用的是VS2003。

在一个项目中谁敢保证每天几千万甚至几亿条的数据不丢失?谁敢保证应用的高可靠性？有可以借签的项目吗？