一切福田,不離方寸,從心而覓,感無不通。

Category Archives: C#

C#与C、Java的区别

C#与C的区别 C#通常不使用指针。 可以在一个方法里的任何地方声明变量,不必把声明语句放在方法的顶端。 使用一个对象前,不一定要声明它,可以在用到的时候再定义。 C#对结构体类型的定义有些不同,它根本不支持联合类型。 C#有枚举类型,允许一系列被命名的量(如颜色或一周里的各天)赋值为连续的数值,但语法有些不同。 C#没有位域,也就是说,变量至少要占用一个字节的存储空间。 C#不支持长参数列表。必须针对参数值和类型定义一个方法。然而,C#语句允许函数的最后一个参数为可变参数数组。 C#引入了代理和索引器的思想,这些在其他流行的语言中是没有的。   C#与Java的区别 C#与Java关系密切,由于C#是在Java之后设计出来的,它吸收了Java的大部分精华。但两者还是有一些细微差别。 许多系统对象方法都有相同的方法名,只是在大小写形式上有区别。 C#不提供throws关键字,该关键字使编译器检查你是否捕获了一个方法抛出的异常。 C#对于布局管理器有更多的限制。因为它是以Windows系统为中心的,大多数时候采取的是图形元素的绝对位置。 C#允许运算符重载。 C#引进了代理和索引器。 C#有枚举类型。 C#有不安全模式,在这种模式下可以使用指针。 必须专门声明一个方法能被覆盖及一个方法能覆盖另一个方法。 不能通过声明来区别继承和接口实现,它们的声明方式是一样的。 switch语句允许使用字符串变量。如果变量没有被匹配,必须有一个默认情况,否则会出现错误。break语句是必需的。 布尔变量类型在C#中拼为“bool”,在Java中拼为“boolean”。 摘自《C#设计模式》

龙生   24 Dec 2018
View Details

ASP.NET WebApi [FromBody]获取对象值一直为null的问题

解决问题前,首先确定[FormBodyAttribute]的定义以及功能范围,相关资料: https://docs.microsoft.com/en-us/aspnet/web-api/overview/formats-and-model-binding/parameter-binding-in-aspnet-web-api 其实文中已经讲得足够详细,一般来讲FormUri获取参数不会存在什么疑惑,但在不了解规则的情况下如何设置和获取FormBody标识的值却有些迷惑:我到底该怎么传递参数api才能够获取到参数?很多文章给出的解决方案是利用="json string"这样的方式进行提交,但实在太别扭了。这样的代码写出去会被打吧…所以,到底该怎么请求呢? 如果你仔细阅读过文章,相信你应该注意到了这一段: When a parameter has [FromBody], Web API uses the Content-Type header to select a formatter.  意思是对于被标记为FromBody的parameter,WebApi默认会根据Content-Type中选择格式化方法。由于Web程序中常常使用JSON方式传递数据,所以这里只针对Content-Type="application/json"的请求进行分析。接着看下一句: In this example, the content type is "application/json" and the request body is a raw JSON string (not a JSON object). 其实到这里已经给出解决方案了,即Content-Type="application/json"的请求都需要将参数转换为JSON string,而非JSON Object. 接下来代码说话的时间到了: 1)创建一个复杂对象的实体类DataParameter: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 [Serializable] public class DataParameter {     public DataParameter() […]

龙生   24 Dec 2018
View Details

ASP.NET MVC学习系列(二)-WebAPI请求

  继续接着上文 ASP.NET MVC学习系列(一)-WebAPI初探 来看看对于一般前台页面发起的get和post请求,我们在Web API中要如何来处理。 这里我使用Jquery 来发起异步请求实现数据调用。   继续使用上一文章中的示例,添加一个index.html页面,添加对jquery的引用。   一、无参数Get请求   一般的get请求我们可以使用jquery提供的$.get() 或者$.ajax({type:"get"}) 来实现:   请求的后台Action方法仍为上篇文章中的GetUser() :   也可以用$.ajax({type:"get"}) 方式,正确的获得了返回数据:   二、传递一个参数的Get请求   通常我们需要传递参数只需要指定ajax方法的data属性即可: data:{"name":"赵大宝"}    后台正确的返回数据:   三、传递两个或多个参数的Get请求   按照上面的方法,对于多个参数我们可以很容易就写出来: data:{"name":"赵大宝","age":12}    后台正确的返回数据: 四、无参数的Post请求   我们可以使用$.post() 或$.ajax({type:"post"}) 来发起post请求:   后台正确的返回了数据: 五、传递一个参数的Post请求:   首先这里需要提醒大家一下,我们在修改完后台代码后,如果没有重新生成项目,那么在请求时就会报错:“未找到与请求***匹配的HTTP资源” :   所以,我们只要我们修改了后台代码,就一定要重新生成一下:     不过,当我们重新生成项目,再次发送请求,看到的仍然是404错误,再次检查一番代码,也没有发现是哪里的问题。   事实上,ASP.NET Web API能够正确的识别我们的UserController控制器处理Post /api/user ,但却不能找到一个可以接受的方法来处理请求。 也就是说,Web API接收到的请求能够找到User控制器,但在该控制器中找不到名称为Def 的这个Action。 那我们要怎么来解决呢? 通过搜索MSDN上Web API官网中的说明,我们可以找到下面的一段介绍: 即在Action 方法中我们需要使用 [FromBody] 属性标签来标明属性。   修改后,再次发送请求,我们可以看到,Status Code 为200,请求发送成功。   可以看到,在post请求中,方法的参数必须要用 [FromBody] 属性来修饰才可以, [FromBody] 就告诉Web API 要从post请求体重去获取参数的值。 但让我们诧异的却是,后台返回的数据中name的值为空。   通过调试,我们可以看到,后台Action 中接收到的name值为null。     通过上面的测试我就也能够猜测到,Web API 要求请求传递的 [FromBody] 参数,肯定是有一个特定的格式,才能被正确的获取到。而这种特定的格式并不是我们常见的 key=value 的键值对形式。Web API 的模型绑定器希望找到 [FromBody] 里没有键名的值,也就是说, 不是 key=value ,而是 =value 。 现在,咱们把data中的key设置为空,然后再次发送请求:   测试可见,后台正确的接收到了数据:  六、传递两个参数的Post请求   按理说,一个参数的请求实现了,那么传递两个或者多个参数也就很顺利了,对于两个参数的后台接收方法,我们可能会这样来写: 但事实证明,这样是错误的。   那到底两个或者多个参数我们要怎样来定义呢? […]

龙生   24 Dec 2018
View Details

webapi “ObjectContent`1”类型未能序列化内容类型“application/xml; charset=utf-8”的响应正文。

今天在来一发  webapi的一个知识点 相信用过webapi的对这个错误 已经看在眼里 痛在心里了把 我百度也搜了一下  看了一下   然后发现他们的解决办法 并没有什么软用。 然后想起来当时上学的时候 老师讲过这个知识点  然后又找到了 老师   0.0 当时老师写的一个笔记。我直接上截图了。   在webapiConfig里面加一行代码 就好。 然后 又是我们熟悉而可爱的json了。   代码是   GlobalConfiguration.Configuration.Formatters.XmlFormatter.SupportedMediaTypes.Clear();   from:https://www.cnblogs.com/uglyman/p/6890706.html?utm_source=itdadao&utm_medium=referral

龙生   19 Dec 2018
View Details

《后端架构师技术图谱》

数据结构 队列 集合 链表、数组 字典、关联数组 栈 树 二叉树 完全二叉树 平衡二叉树 二叉查找树(BST) 红黑树 B,B+,B*树 LSM 树 BitSet 常用算法 排序、查找算法 选择排序 冒泡排序 插入排序 快速排序 归并排序 希尔排序 堆排序 计数排序 桶排序 基数排序 二分查找 Java 中的排序工具 布隆过滤器 字符串比较 KMP 算法 深度优先、广度优先 贪心算法 回溯算法 剪枝算法 动态规划 朴素贝叶斯 推荐算法 最小生成树算法 最短路径算法 并发 Java 并发 多线程 线程安全 一致性、事务 事务 ACID 特性 事务的隔离级别 MVCC 锁 Java中的锁和同步类 公平锁 & 非公平锁 悲观锁 乐观锁 & CAS ABA 问题 CopyOnWrite容器 RingBuffer 可重入锁 & 不可重入锁 互斥锁 & 共享锁 死锁 操作系统 计算机原理 CPU 多级缓存 进程 线程 协程 Linux 设计模式 设计模式的六大原则 23种常见设计模式 应用场景 单例模式 […]

龙生   19 Dec 2018
View Details

Tuple.cs

 

龙生   14 Dec 2018
View Details

C#中HttpClient使用注意:预热与长连接

原文地址:C#中HttpClient使用注意:预热与长连接 最近在测试一个第三方API,准备集成在我们的网站应用中。API的调用使用的是.NET中的HttpClient,由于这个API会在关键业务中用到,对调用API的整体响应速度有严格要求,所以对HttpClient有了格外的关注。 开始测试的时候,只在客户端通过HttpClient用PostAsync发了一个http post请求。测试时发现,从创建HttpClient实例,到发出请求,到读取到服务器的响应数据总耗时在2s左右,而且多次测试都是这样。2s的响应速度当然是无法让人接受的,我们希望至少控制在100ms以内。于是开始追查这个问题的原因。 在API的返回数据中包含了该请求在服务端执行的耗时,这个耗时都在20ms以内,问题与服务端API无关。于是把怀疑点放到了网络延迟上,但ping服务器的响应时间都在10ms左右,网络延迟的可能性也不大。 当我们正准备换一个网络环境进行测试时,突然想到,我们的测试方式有些问题。我们只通过HttpClient发了一个PostAsync请求,假如HttpClient在第一次调用时存在某种预热机制(比如在EF中就有这样的机制),现在2s的总耗时可能大多消耗在HttpClient的预热上。 于是修改测试代码,将调用由1次改为100次,然后恍然大悟地发现——只有第1次是2s,接下来的99次都在100ms以内。果然是HttpClient的某种预热机制在搞鬼! 既然知道了是HttpClient预热机制的原因,那我们可以帮HttpClient进行热身,减少第一次请求的耗时。我们尝试了一种预热方式,在正式发http post请求之前,先发一个http head请求,代码如下:

经测试,通过这种热身方法,可以将第一次请求的耗时由2s左右降到1s以内(测试结果是700多ms)。 在知道第1次HttpClient请求耗时2s的真相之后,我们将目光转向了剩下的99次耗时100ms以内的请求,发现绝大部分请求都在50ms以上。有没有可能将之降至50ms以下?而且,之前一直有这样的纠结:每次调用是不是一定要对HttpClient进行Dispose()?是不是要将HttpClient单例或者静态化(声明为静态变量)?借此机会一起研究一下。 在HttpClient的背后,有一个对请求响应速度有着不容忽视影响的东东——TCP连接。一个HttpClient实例会关联一个TCP连接,在对HttpClient进行Dispose时,会关闭TCP连接(我们用Wireshark进行网络抓包也验证了这一点)。 在之前的测试中,我们每次用HttpClient发请求时,都是新建一个HttpClient实例,用完就对它进行Dispose,代码如下:

所以每次请求时都要经历新建TCP连接->传数据->关闭连接(也就是通常所说的短连接),而且雪上加霜的是请求用的是https,建立TCP连接时还需要一个基于公私钥加解密的key exchange过程:Client Hello -> Server Hello -> Certificate -> Client Key Exchange -> New Session Ticket。 如果我们想将请求响应时间降至50ms以下,就必须从这个地方下手——重用TCP连接(也就是通常所说的长连接)。要实现长连接,首先需要的就是在HttpClient第1次请求后不关闭TCP连接(不调用Dispose方法);而要让后续的请求继续使用这个未关闭的TCP连接,我们必须要使用同一个HttpClient实例;而要使用同一个HttpClient实例,就得实现HttpClient的单例或者静态化。之前的3 个问题,由于要解决第1个问题,后2个问题变成了别无选择。 为了实现长连接,我们将HttpClient的调用代码改为如下的样子:

然后测试一下请求响应时间:

除了第1次请求,接下来的99次请求绝大多数都在50ms以内。TCP长连接的效果必须的! 通过Wireshak抓包也验证了长连接的效果: 这时,你也许会产生这样的疑问:将HttpClient声明为静态变量,会不会存在线程安全问题?我们当时也有这样的疑问,后来在stackoverflow上找到了答案:

HttpClient的所有异步方法都是线程安全的,放心使用。 到这里,HttpClient的问题是不是可以完美收官了?。。。稍等,还有一个问题。 客户端虽然保持着TCP连接,但TCP连接是两口子的事,服务器端呢?你不告诉服务器,服务器怎么知道你要一直保持TCP连接呢?对于客户端,保持TCP连接的开销不大;但是对于服务器,则完全不一样的,如果默认都保持TCP连接,那可是要保持成千上万客户端的连接啊。所以,一般的Web服务器都会根据客户端的诉求来决定是否保持TCP连接,这就是keep-alive存在的理由。 所以,我们还要给HttpClient增加一个Connection:keep-alive的请求头,代码如下:

现在终于可以收官了。但是肯定不完美,分享的只是解决问题的过程。   from:https://www.cnblogs.com/JustYong/p/5872296.html

龙生   07 Oct 2018
View Details

C# HttpClient请求

  from:https://www.cnblogs.com/louby/p/8021527.html

龙生   07 Oct 2018
View Details

C# HttpClient设置cookies的两种办法 (转发)

一般有两种办法 第一种handler.UseCookies=true(默认为true),默认的会自己带上cookies,例如

这种情况post请求登陆成功后,重定向到别的页面,也会自动带上cookies。如果把handler.UseCookies设置为false,登陆后重定向的话不会自动带上cookies,则又会跳转到登陆页面。   第二种设置 handler.UseCookies = false时,则需要手动给headers上加入cookies.

如果使用场景是:抓取需要登陆后才能看到的网页数据,建议使用第一种,不需要设置任何cookies,httpclient会自动把登陆后的cookies放置到后面的请求中。   原贴 : http://www.cnblogs.com/xiaozhu39505/p/8033108.html from:https://www.cnblogs.com/refuge/p/8060142.html

龙生   07 Oct 2018
View Details

C#中将字符串通过GZipStream进行压缩时的注意事项

背景, 今天在写代码时要用到GZipStream来压缩需要Web传输的数据块。原本以为GZipStream Write ->Flush ->读取对应MemoryStream数据就Okay的事情,却总是得不到正确的结果。 研究, 经过查询MSDN,原来只有在GZipStream被Dispose后,对应的MemoryStream中才会有真正的压缩数据被写入。 以下是我用来测试的代码片段(红色部分为原来的错误调用,橙色部分是正确的调用方式) string data = "<Root><PIGContent>test</PIGContent><RemoteUrl>http://www.a.com</RemoteUrl></Root>"; byte[] buffer = System.Text.UTF8Encoding.UTF8.GetBytes(data); byte[] compressedbuffer = null; //Compress buffer MemoryStream ms = new MemoryStream(); using(GZipStream zs = new GZipStream(ms, CompressionMode.Compress,true)) { zs.Write(buffer, 0, buffer.Length); //下面两句被注释掉的代码有问题, 对应的compressedbuffer的长度只有10--该10字节应该只是压缩buffer的header //zs.Flush(); //compressedbuffer = ms.ToArray(); } //只有GZipStream在Dispose后调应对应MemoryStream.ToArray()所得到的Buffer才是我们需要的结果 compressedbuffer = ms.ToArray(); 总结, 相信大家都会对GZipstream这种别扭的操作方式表示不满,微软对此也表示过歉意,但是由于其考虑到要兼容就的代码,因此即使在.Net 4.5中你还是得忍受这种不和谐的代码。 本篇小结如有不妥之处,烦请指正。   from: https://blog.csdn.net/missautumn/article/details/8351296

龙生   03 Aug 2018
View Details
1 8 9 10 43