WEB开发网
开发学院软件开发Delphi 关于动态代理 阅读

关于动态代理

 2006-02-04 13:59:30 来源:WEB开发网   
核心提示:本来想上周末没能用DELPHI实现动态代理就算了,可是这几天却始终放不下这个想法,关于动态代理,这实在是一个太美妙的想法了,而且在认真看了VCL对SOAP的实现后,就不得不面对TInvContext的内部复杂性,易用性太差,现在至少有九成的把握可以实现这样一个动态代理, 那么动态代理有什么用?这要先从GoF的PRoxy
本来想上周末没能用DELPHI实现动态代理就算了,可是这几天却始终放不下这个想法,这实在是一个太美妙的想法了。而且在认真看了VCL对SOAP的实现后,现在至少有九成的把握可以实现这样一个动态代理。

那么动态代理有什么用?

这要先从GoF的PRoxy模式说起。

假设有下面这样一个接口及其实现:

现在,如果你是这个接口的用户,而这个接口及其实现者提供了一个:

  Foo : IFoo;

给你,其中Foo指向TFooImpl的一个实例。现在你有了IFoo的定义,和这个Foo实例--注意,你没有TFooImpl的定义和实现代码。如果现在要求你为所有的IFoo.doSth增加事务功能(假设doSth被实现为对数据库作更新操作),要怎么办?

GoF的Proxy模式就是解决方案之一:

如果所示,首先要实现一个新的IFoo接口实现--TStaticProxy。其中用了一个属性FImpl记录了TFooImpl的实例。然后在 TStaticProxy中实现doSth和bar,并且将不需要变更的bar函数直接委托给FImpl处理,而在doSth的实现里加入事务处理即可。 TStaticProxy的代码大致如下:

TStaticProxy = class( TInterfacedObject, IIFoo )
private
  FImpl : IFoo;
public
  constructor Create( aImpl : IFoo );
  function doSth( ... ) : xxx;
  function bar( ... ) : xxx;
end;

constructor TStaticProxy.Create( aImpl : IFoo );
Begin
  FImpl := aImpl;
End;

function TStaticProxy.doSth( ... ) : xxx;
Begin
  BeginTransaction;
  Result := FImpl.doSth( ... );
  EndTransaction;
End;

function TStaticProxy.bar( ... ) : xxx;
Begin
  Result := FImpl.bar( ... );
End;

然后,在所有需要用到Foo对象的地方,改用新的NewFoo对象,如下:

var
  NewFoo : IFoo;
Begin
  NewFoo := TStaticProxy.Create( Foo ) As IFoo;
  ...  //  之后就可以把NewFoo完全当作Foo一样使用了。
End;

可见,我们通过了一个Proxy类代理了所有对IFoo接口的操作,相当于在从IFoo到TFooImpl之间插入了自己的代码,在某种程度上,这就是AOP所谓的“横切”。当然如果你能有TFooImpl的代码的话,就简单了,只要如下:

从TFooImpl派生一个TNewFooImpl,然后在其中Override一下TFooImpl中的doSth即可,然后就创建TNewFooImpl的实例来代替Foo引用即可。

但问题就在于你必须拥用TFooImpl的代码,并且可以变更所提供的Foo实例,但这在很多时候是做不到的--除非不是用DELPHI,而是如 Python一类的动态语言^O^。比如组件容器,比如远程实例等。还有像“虚代理”(就是当创建FImpl代价很高时,就在创建时只创建代理类,然后在真正需要时才创建FImpl的实例)

但上面这种静态代理还是很麻烦。首先,如果IFoo的成员函数很多的话,必须要一一为它们加上代理实现;其次,如果在应用中有很多接口需要代理时,就必须一一为它们写这样的专用代理类;第三,需要变更代理功能时,需要修改所有的代理类……

特别是像组件容器或是通用远程代理这样,对要实现的接口并不能确定的情况下,静态代理一点用也没有。

所以我们需要“动态代理”。我是在看了GIGIX发表在今年第一期《程序员》上的《动态代理的前世今生》一文后,虽然他说是的java在 JDK1.3中提出的,在java.lang.reflect中的proxy。但这却让我突发奇想,发现其实完全可以在DELPHI里也实现这样一个动态代理。

一个典型的动态代理如下:

这样,我们只需要把要增加在功能做成一个IInvocationHandler接口的实例,如图中的TFooInvHandler。然后动态创建一个支持IFoo接口的TDynamicProxy的实例--它是一个动态代理,只需要传入相应的参数:要实现的接口和相应的InvHandler实例即可,不需要为每个接口写一个代理。当然如GIGIX文中所说,对于C++来说,这个可以用模板实现,但问题在于模板归根到底是一种编译时的动态化技术,对于组件容器这样需要运行时动态化的应用,它还是不能实现。最后,InvHandler通过RTTI去调用具体的实现Foo。

它的用法大致如下:

TFooInvHandler = class( TInterfacedObject, IInvocationHandler )
private
  FImpl : IFoo;
public
  constructor Create( aImpl : IFoo );
  function Invoke( IID, MethodName, Args[] ) : xxx;
end;

constructor TFooInvHandler.Create( aImpl : IFoo );
Begin
  FImpl := aImpl;
End;

function TFooInvHandler.Invoke( IID, MethodName, Args[] ) : xxx
Begin
  If ( IID = IFoo ) AND ( MethodName = 'doSth' ) Then
  Begin
     BeginTransaction;
     Result := DoInvoke( FImpl, IID, MethodName, Args[] );
     EndTransaction;
  End
  Else
     Result := DoInvoke( FImpl, IID, MethodName, Args[] );
End;

var
  Handler : IInvocationHandler;
  NewFoo : IFoo;
Begin
  Handler := TFooInvHandler.Create( Foo );
  NewFoo := TDynamicProxy.Create( TypeInfo(IFoo), Handler ) As IFoo;
  ...  //  之后就可以把NewFoo完全当作Foo一样使用了。
End;

注意:其中IInvocationHandler接口我还没想好要怎么定义,所以这段代码只是大致说明一下问题。另外,其中的DoInvoke就是通过RTTI来调用FImpl的。

从上面的代码可以看到,TDynamicProxy通过参数IFoo动态生成了一个对IFoo接口的代理,并且通过Handler参数插入一个处理接口IInvocationHandler,由TDynamicProxy把对IFoo接口的调用全部转成对IInvocationHandler接口的调用,最后由TFooInvHandler类来视情况处理。在这里,可以通过运行时配置方式来动态决定是否需要切入事务所处理,需要对哪个接口的哪个方法切入。

有了这样一个动态代理,还可以很方便地在InvocationHandler里切入如安全性检查,LOG等。这样的话,用DELPHI来实现AOP也不成问题了。

现在我面临的问题就是:如何来定义这个IInvocationHandler。

其实这里最主要的问题就是参数的传递的问题。接口可以用IID表示,方法可以用方法名,但参数变化太多了:一是数量不确定,可以有任意多个参数;二是类型不确定;三是传值参数和引用参数的问题。如前面那个例子用的是简单的办法,就是用一个不定长的Variant数组来记录,可以解决前两个问题,但第三个问题就比较麻烦,难道要用一个Tuple来作返回值?太麻烦了吧。

在VCL的SOAP实现里是通过一个TInvContext在记录的,但这样的话对于Handler的开发者来说,就不得不面对TInvContext的内部复杂性,易用性太差。

这就是我现在还不能确定实现的那一成。-_-|||

Tags:关于 动态 代理

编辑录入:爽爽 [复制链接] [打 印]
赞助商链接