.NET简谈组件程序设计之(详解NetRemoting结构)
来源：网络 责任编辑：栏目编辑 发表时间:2013-07-01 07:07 点击:次
在本人的上一篇文章中只是简单的介绍了一下.NETRemoting的一般概念和基本的使用。这篇文章我想通过自己的学习和理解将对.NETRemoting的整体的一个框架进行通俗的讲解，其中最重要的就是信道(管道)处理模型思想，这里面蕴含了很多的设计原理
.NETRemoting远程处理架构是一个半成品，是.NET给我们的扩展框架，要想用于商业项目必须进行一些安全、性能方面的控制。要想进行一定深度的扩展那就要必须了解它的整体结构，各个点之间的关系才能很好的控制它。
网上讲解.NETRemoting的文章很多，但是通俗易懂的没有几篇，都是大概讲解了一下整体模型或者从MSDN上COPY过来，未能对各模型之间的接口做详细讲解。了解.NETRemoting的朋友都知道，它的实现基本上都是通过接口与接口之间的串联形成处理管道，这也让我们想起来了设计模式中首要提及的面向对象设计思想“面向接口编程”。
本人在学习.NETRemoting的时候还是比较痛苦的，由于中文资料缺乏只能通过搜索网上零零散散的知识点再通过拼命的理解、换位思考、提高抽象层次，才终于参透为什么那么多接口之间的关系，在这里小弟会一一讲解那些诸如IClientChannelSink、IClientChannelSinkProvider、IMessageSink等等接口到底是什么意思，提供程序与信道接收器之间又是啥关系，在信道处理模型中是怎么利用多态来设计的。
.NETRemoting处理管道
在.NETRemoting中它的整体处理模型有点像ASP.NET中的HTTP处理管道模型，消息从最上面的入口进入然后一个一个的传递到各个处理模块中，这样就形成了一个抽象的处理管道。
图1（客户端信道处理）：
这是客户端信道处理模型的大概结构。任何客户端对跨远程处理都是通过代理进行的，代理分为两部分一种是透明代理，一种是真实代理；
透明代理是通过真实代理动态生成的，透明代理的所有成员都是客户端将要调用的远程对象的一个虚拟镜像。为什么要说是虚拟的，是因为透明代理只是方便客户端调用的，当我们NEW一个远程对象时，系统将为我们动态的生成一个继承自你NEW的那个对象的代码，然后动态生成内存透明代理对象。
透明代理包括了对真实代理的调用，真正的幕后主脑是RealProxy对象，它包括了对信道处理结构的引用。在上面的图1中为什么真实代理是用IMessageSink接口来启动整个信道处理模型的。这里也是最为难理解的入口点，下面我们将自己的抽象能力提升一个层次才能知道系统为什么要这样设计
图2（服务器端信道处理）：
相关新闻>>
最新推荐更多>>>
- 发表评论
-
- 最新评论 更多>>
