欢迎来到.net学习网

欢迎联系站长一起更新本网站!QQ:879621940

您当前所在位置:首页 »  .NET本质论第一卷:公共语言运行库教程 » 正文

本教程章节列表

.net本质论-第七章:高级方法

创建时间:2013年01月24日 12:24  阅读次数:(3623)
分享到:
第6章阐述了用于调用方法的各种实用部件。然而,一旦方法被调用,控制权就被传递给目标对象的方法,调用过程就结束了。本章主要讨论由CLR提供的用于在调用方和被调用方之间截获调用过程的各个实用部件。

尤其需要注意的是:本章描述的一部分方法凋用架构,很可能会在将来的CLR版本中得以显著地发展。换而言之,本章提到的许多概念和技术到将来仍然有效。本章论述的侧重点在于对完整性的考虑,而不仅仅是作为给读者的介绍。

动机


软件工程的大多数思想重点在于管理复杂性。结构化编程试图通过对代码和设计进行粗糙地分离,以减少复杂性:面向对象编程试图通过构建抽象事物,将状态和行为组合在一起,以减少复杂性:组件通过基于抽象接口或者协议分离应用程序,以减少复杂性。组件的意图就是为了让技能不高的程序员,使用高级语言或者工具对组件进行装配。当然,这是基于一种假设前提,即问题域(problem domain)可以被分解成离散的组件,它们只是通过简单的方法调用相互作用,

组件的基本前提忽略了—个事实,那就是程序的某些方面(aspect)可能渗透到应用程序的所有部分。安全性就是这样的一个方面。此外,还有线程管理、并发性控制等等。

应用程序中通常会掺杂一些代码片段(tiny snippets),来处理程序的那些方面,而它们并不是问题域的中心。这样的方面往往是跨问题域的,并且要求有可重用的解决方案。对于这类问题提供可重用的机制是面向方面蝙程(aspect-oriented programming,AOP)的重点。这里,AOP是一个由XefOXPARC研究中心的Gregor Kiczales在1997年创建的术语。

AOP的重点在于提供一种机制将应用程序分解成多个块.这些块是建立在concern分离的原则上的,与问题域关系不大。这样做有两个好处.第一,应用程序的代码不再被那些“管道(plumbing)代码掺合,而后者与待解决的问题并没有什么关系:第二,通过将跨问题域的代码的这些方面分解出来,你可以在其他应用程序中重用这些解决方案。

微软事务服务器( MicrosofC Transaction Server,MTS)应该是最先广泛采用AOP的应用程序。MTS提供了一种特性机制,可以用来表示程序的不同方面,例如,常规代码流之外的事务性和安全性。MTS通过截获(interception)实现这些方面。MTS自身将插入到调用方和组件之间,并预处理(preprocess)或后处理(postprocess)组件中的各个方法调用。在预处理和后处理期间,MTS执行程序(MTS executive)将管理事务、处理安全检查,以及激活对象。对于组件开发人员而言,所有这些都不需要显式地编码。尽管事务极可能影响组什的整个设计,但是并不需要显式地编码来管理事务。更进一步地说,MTS执行程序将在后台静静地处理所有这些问题。

在COM时代构建MTS风格的截获管道(interception  plumbing)是相当困难的。原因之一就是缺乏高保真的(high-fidelity)可扩展元数据.显而易见,在基于CLR的世界中,这不再是问题。COM时代的另一个难题是:要透明地插入代码,且不能弄乱了堆栈,就要处理IA-32调用堆栈的特别性(peculiarity)。为了避免堆栈的混合(melt),总是需要求助于IA-32汇编语言。CLR架构的主要目标之一,就是提供一个通用的截获机制,使我们不用求助于讨厌的底层编码技术,而插入用户自定义的这些方面。CLR的截获机制的最基本概念就是调用能被当作消息进行交换。

作为方法调用的消息


CLR提供了一个丰富的架构,用于将方法调用模型化,使它可以作为消息进行交换。选种架构对于构建AOP风格的截获、RPC风格的通信机制,以及处理异步调用都是很有用的,实际上,在第6章描述的异步方法调用功能就使用这种架构,理解这种架构的关键点就是重新考察方法实际上做了什么。归根结底,方法只是在堆栈上进行简单地内存转换。顺便说一句,功能化编程的拥护者(functional programming advocates)认为这就是方法的全部。调用方通过以方法指定的格式将适台的参数压入堆栈,从而形成一个调用堆栈。在控制权被传递给方法之后,这个方法的主要工作便是处理传递给堆栈的参数,并且重写堆栈以表明处理的结果。图7.l描述了这个过程。
方法调用和堆栈帧

CLR允许你以消息交换的形式,对这种堆栈帧(stack frame)的转换进行模型化。在这种消息交换的模型中,一个方法调用有两个消息:一个表示调用请求,另一个表示调用结果。为了按可编程的方式进行访问,CLR将这些消息模型化,即将它们作为实现了System.Runtime.Remoting.Messiging.IMessage接口的对象。如图7.2所示,IMessage充当在套件(suite)中其他接口的基接口。这些接口中最令人感兴趣的是IMethodMessage。
IMessage类型层次结构
using System.Reflecton;
using System.Collectons;
namespace System.Runtime.Remoting.Messageing{
public interface IMessage{
IDictionary Properties{get;}
}

public interface IMethodMessage:IMessage{
object GetArg(intindex);
string GetArgName(int index);

int ArgCount{get;}
object[] Args{get;}
bool HasVarArgs{get;}
LogicalCallContext LogicalCallContext{get;}
MethodBase MethodBase{get;}
string Methodname{get;}
object MethodSignature{get;}
string TypeName{get;}
string Uri{get;}
}
}

注意,除了提供对方法参数的访问之外,IMethodMessage接口还提供 了MethodBase属性,用于访问方法的元数据。通过这个通用接口公开堆栈帧的好处就足:它允许你访问堆栈的内容,而不需要知道底层的堆栈帧布局。例如,考虑下面的代码:
static void WireTap(IMethodMessage msg)
{
IMethodCallMessage call=(IMethodCallMessage)msg;
Console.WriteLine("<{0}>",call.MethodName);
for(int i=0;i<call.ArgCount;++i)
{
Console.WriteLine("<{0}>{0}</{0}>",call.GEtArgName(i),call.GEtArg(i),Call.GEtArgName(i));
}
Console.WriteLine("</{0}>",call.MethodName);
}

假定这个例程被表示的消息对应于下面的调用:
int b=2;
int c=3;
int n=foo.MyMetthod(1,ref b,out c);

这将显示下面的结果:
<MyMethod>
<arg1>1</arg1>
<arg2>2</arg2>
<arg3>3</arg3>
</MyMethod>

这种机制的强大之处在于:Wiretap方法不需要事先知道MethodName的签名。这是因为IMethodMessage接口将调用堆栈虚拟化成一个合理的可编程的抽象体。
来源:.net学习网
说明:所有来源为 .net学习网的文章均为原创,如有转载,请在转载处标注本页地址,谢谢!
【编辑:Wyf】

打赏

取消

感谢您的支持,我会做的更好!

扫码支持
扫码打赏,您说多少就多少

打开支付宝扫一扫,即可进行扫码打赏哦

最新评论

共有评论0条
  • 暂无任何评论,请留下您对本文章的看法,共同参入讨论!
发表评论:
留言人:
内  容:
请输入问题 28+21=? 的结果(结果是:49)
结  果: