在默认的情况下，EnterLib的PIAB采用基于透明/真实代理的机制实现对方法调用的拦截，进而实现了对横切关注点的动态注入。也正是其来截机制本身的局限，当我们才用PIAB的方式进行对象的创建的时候，要求对象的类型要么实现某一个接口，要么直接继承MarshalByRefObject类型。但不支持通过抽象基类对该类的间接继承，我个人觉得这是微软需要改进的地方。
在默认的情况下，EnterLib的PIAB采用基于TransparentProxy/RealProxy的机制实现对方法调用的拦截，进而实现了对横切关注点（Crosscutting Concern）的动态注入。也正是其来截机制本身的局限，当我们才用PIAB的方式进行对象的创建的时候，要求本创建对象的类型要么实现某一个接口，要么继承MarshalByRefObject类型。但是当我们让抽象基类继承自MarshalByRefObject就不行了，我个人觉得这是微软需要改进的地方。
一、基于接口实现和对MarshalByRefObject直接继承的编程
我们先来看看PIAB默认支持的编程方法。为此便于演示，我创建了一个自定义的CallHandler：FooCallHandler。在Invoke方法中，我在调用目标方法前后在控制台输出相应的文字，表明该CallHandler得以正常执行。下面是FooCallHandler和它对应的HandlerAttributed的定义：
1: public class FooCallHandler : ICallHandler
2: {3: public IMethodReturn Invoke(IMethodInvocation input, GetNextHandlerDelegate getNext)
4: {5: Console.WriteLine("PreOperation...");6: var methodReturn = getNext()(input, getNext);
7: Console.WriteLine("PostOperation...");8: return methodReturn;
9: }
10:
11: public int Order { get; set; }12: }
13:
14: public class FooCallHandlerAttribute : HandlerAttribute
15: {16: public override ICallHandler CreateHandler(IUnityContainer container)
17: {18: return new FooCallHandler { Order = this.Order };19: }
20: }
先来模拟以及接口实现的编程方式，为此我们定义了一个接口IFoo，实现该接口的类型Foo。IFoo和Foo定义在如下的代码片断中，上面创建的FooCallHandler通过自定义特性的方式应用到类型Foo上面。在Main方法中，调用PolicyInjection的泛型方法Create，并指明接口和具体类型的方式来创建Foo对象。
1: class Program
2: {3: static void Main()
4: {5: var foo = PolicyInjection.Create<Foo, IFoo>();
6: foo.DoSomething();
7: }
8: }
9: public interface IFoo
10: {11: void DoSomething();
12: }
13: [FooCallHandler]
14: public class Foo : IFoo
15: {16: public void DoSomething()
17: {18: Console.WriteLine("Do something...");19: }
20: }
从下面的输出我们可以看出，应用在类型Foo上面的FooCallHandler在目标方法被调用之前先得到了执行。
1: PreOperation...
2: Do something...
3: PostOperation...
你也可以让Foo直接继承自MarshalByRefObject。如果你执行下面的代码，你依然可以得到与上面一样的输出结果：
1: class Program
2: {3: static void Main()
4: {5: var foo = PolicyInjection.Create<Foo>();
6: foo.DoSomething();
7: }
8: }
9: [FooCallHandler]
10: public class Foo : MarshalByRefObject
11: {12: public void DoSomething()
13: {14: Console.WriteLine("Do something...");15: }
16: }
二、将接口变成抽象类
我们推荐面向抽象的编程方式，具体有两种主要的表现：基于接口编程和基于抽象类编程。现在，我们将接口IFoo换成抽象类FooBase，具体改变如下所示。
1: class Program
2: {3: static void Main()
4: {5: var foo = PolicyInjection.Create<Foo, FooBase>();
6: foo.DoSomething();
7: }
8: }
9:
10: public abstract class FooBase
11: {12: public abstract void DoSomething();
13: }
14:
15: [FooCallHandler]
16: public class Foo: FooBase
17: {18: public override void DoSomething()
19: {20: Console.WriteLine("Do something...");21: }
22: }
上面的程序运行后，会抛出如下图所示的ResolutionFailedException异常。错误消息表明异常是应该FooBase不能被实例化导致的——FooBase是抽象类。但是我们实例化的时具体类型Foo，FooBase能否实例化与此无关。
三、让FooBase继承MarshalByRefObject
上面我们说过，能被PIAB进行拦截的类型要么实现一个接口，要么继承MarshalByReObject类。如果我们将FooBase继承自MarshalByReObject，是否会避免上述异常的抛出呢？为此，我们对FooBase加上了这个基类。
1: public abstract class FooBase: MarshalByRefObject
2: {3: public abstract void DoSomething();
4: }
运行我们的程序，会抛出和上面完全一样的异常。
四、抽象类可以这样用
经过我的实验，抽象类可以这样用：将继承自MarshalByRefObject的具体类作为抽象类的基类。按照这个原理，我们对上面的例子作了如下改动：将FooBase从抽象类换成具体类，将Foo变成抽象类（Foo依然继承自FooBase），然后创建另一个继承自Foo的具体类FooImpl。
1: class Program
2: {3: static void Main()
4: {5: var foo = PolicyInjection.Create<FooImpl, FooBase>();
6: foo.DoSomething();
7: }
8: }
9: public class FooBase: MarshalByRefObject
10: {11: public virtual void DoSomething()
12: {13: throw new NotImplementedException("This method must be implemented by subclasses");14: }
15: }
16: public abstract class Foo : FooBase { }17: [FooCallHandler]
18: public class FooImpl : Foo
19: {20: public override void DoSomething()
21: {22: Console.WriteLine("Do something...");23: }
24: }
作了如此修改后，运行我们的程序之后我们能够得到正确的结果。不过，为了让PIAB提供对抽象类的支持而多加上一个非抽象的基类，在设计上是很丑陋的，我个人是不能接受的。实际上，我觉得这是PIAB自身的一个BUG，或者是自身欠考虑的地方。因为在实现的可行性上没有任何问题。我亲自在我自己开发的基于TransparentProxy/RealProxy的AOP框架（《自己动手创建迷你版AOP框架》）中经过验证，让抽象类继承MarshalByRefObject，并基于该抽象类创建一个可被拦截的TransparentProxy对象是可以实现的。
作者：Artech
