HttpWebRequest、WebClient、HttpClient深入学习

今天学习了C#中的HttpWebRequest、WebClient、HttpClient使用及区别，简要总结：

HttpWebRequest是老版本.net下常用的，较为底层且复杂，访问速度及并发也不甚理想（有机会可以写代码测试对比下）不会阻塞UI线程，通常和WebResponse一起使用，一个发送请求，一个获取数据。

WebClient是更高级别的抽象，在功能上更加简单易用，细节控制上较少，但速度稍慢一些（据说几毫秒）。

HttpClient是.net4.5之后引入的，利用了面向任务模式，容易进行异步请求，初次访问较慢，适合使用单例模式获取。

转一张图

 

抱着深入学习的想法，查看了各个方法的继承类：

HttpWebRequest继承自 WebRequest, ISerializable

WebRequest ： MarshalByRefObject, ISerializable

MarshalByRefObject 是通过使用代理交换消息来跨应用程序域边界进行通讯的对象的基类.MarshalByRefObject 对象在本地应用程序域的边界内可直接访问。远程应用程序域中的应用程序首次访问MarshalByRefObject 时，会向该远程应用程序传递代理。对该代理后面的调用将封送回驻留在本地应用程序域中的对象。当跨应用程序域边界使用类型时，类型必须是从 MarshalByRefObject 继承的，而且由于对象的成员在创建它们的应用程序域之外无法使用，所以不得复制对象的状态。

MarshalByRefObject中的"Marshal"应该怎样理解？当一个对象需要长途跋涉到另一个环境中时，需要将其marshal成一个可以传输的形态（比如在.NET Remoting中对象将被打包成一个serializable的ObjRef实例——这个ByRef就是指ObjRef这种形态）；同理，当打包以后传输到目标地点，还要执行unmarshal的操作将其还原为内存中的对象。（https://blog.csdn.net/cnhk1225/article/details/50351603）

ISerializable接口：继承ISerializable接口可以灵活控制序列化过程。格式化器的工作流程：格式化器再序列化一个对象的时候，发现对象继承了ISerializable接口，那它就会忽略掉类型所有的序列化特性，转而调用类型的GetObjectData方法来构造一个SerializationInfo对象。我们在方法GetObjectData中处理序列化，然后在一个带参数的构造方法中处理反序列化。虽然在接口中没有地方指出需要这样一个构造器，但这确实是需要的，除非我们序列化后不再打算把它反序列化回来。

MarshalByRefObject 和Serializable的区别

这两种方式的类一般都是用于远程传输时使用。marshalbyrefobject是通过引用传递,serializable是通过值传递，现在就来分析下什么是引用传递，什么是值传递。理解这个对Remoting或者webservice的认识是很重要的。marshalbyrefobject（引用）本机或者是服务器上的其实都是同一个实例，只不过是服务器创建后你在本地使用了那个对象而已。比如说A类继承了marshalbyrefobject那么A类由服务器创建实例了，客户端都可以使用这个实例了。

现在我们假设A类有一个方法叫着A,Function返回值为一个string类型这个方法有一系列的操作。客户端在调用这个方法的时候只得到服务器返回的一个值，那个一系列的操作都将在服务器完成，这就是所谓的馊客服端。

Serializable（值类型）这个就不同了，假定我们刚才的那个A类的Funciton方法需要一个B类作为参数，B是一个可序列化的类，也就是类的定义上面加了[Serializable()]，如果没加那么这个方法将会报错。(案例参考：https://www.cnblogs.com/ChineseMoonGod/p/6121356.html)

我建了个netstandard的库发现MarshalByRefObject在netcore中已经不再支持了，发现.net core将整个Remoting都抛弃了

 

WebClient，继承自Component，

Component继承自 MarshalByRefObject, IComponent, IDisposable

下次再写Component。。