ContextAttribute与ContextBoundObject应用的探究

这两天因开发的需要，需要分析和构建针对ContextAttribute极其ContextBoundContext相关的拦截器的内容，所以今天一上班就开发分析ContextAttribute与ContextBoundContext之间的应用关系，在查看了相关网友的资源后开始了我的分析之路。
  首先：我建立了一个ContextAttribute的子类和一个普通的Attribute子类，分别附加在ContextBoundContext子类和普通子类上。代码如下：

using System;
using System.Collections.Generic;
using System.Text;

using System.Runtime.Remoting.Contexts;
using System.Runtime.Remoting.Activation;

namespace ContextDemo
{
    public class DemoContextAttribute : ContextAttribute
    {
        public DemoContextAttribute()
            : base("DemoContextAttribute")
        {
            Console.WriteLine("Call 'DemoContextAttribute' - 'Constructor' ");
        }
    }

    public class NonContextAttribute : Attribute
    {
        public NonContextAttribute()
        {
            Console.WriteLine("Call 'NonContextAttribute' - 'Constructor' ");
        }
    }

    [DemoContext]
    [NonContext]
    public class DemoContextBoundObject : ContextBoundObject
    {
        public DemoContextBoundObject()
        {
            Console.WriteLine("Call 'DemoContextBoundObject' - 'Constructor' ");
        }
    }

    [DemoContext]
    [NonContext]
    public class NonContextBoundObject
    {
        public NonContextBoundObject()
        {
            Console.WriteLine("Call 'NonContextBoundObject' - 'Constructor'  ");
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Begin Main ");

            DemoContextBoundObject dcbo = new DemoContextBoundObject();
            NonContextBoundObject ncbo = new NonContextBoundObject();

            Console.WriteLine("End Main ");

            Console.Read();
        }
    }
}

执行的结果如下：

这里可以看出，只有继承于ContextAttribute的子类在ContextBoundObject上使用才会进行构造。其实都没有进行调用。
 然后：我将ContextAttribute之下的虚方法都进行了一次继承并且添加相应的查看信息来分析各个方法的调用顺序，代码如下：

using System;
using System.Collections.Generic;
using System.Text;
using System.Runtime.Remoting.Contexts;
using System.Runtime.Remoting.Activation;

namespace ContextDemo {
    public class DemoContextAttribute : ContextAttribute {
        public DemoContextAttribute()
            : base("DemoContextAttribute") {
            Console.WriteLine("Call 'DemoContextAttribute' - 'Constructor' ");
        }

        public override void Freeze(Context newContext) {
            Console.WriteLine("Call 'DemoContextAttribute' - 'Freeze' ");
        }

        public override void GetPropertiesForNewContext(IConstructionCallMessage ctorMsg) {
            Console.WriteLine("Call 'DemoContextAttribute' - 'GetPropertiesForNewContext' ");
            base.GetPropertiesForNewContext(ctorMsg);
        }

        public override bool IsContextOK(Context ctx, IConstructionCallMessage ctorMsg) {
            Console.WriteLine("Call 'DemoContextAttribute' - 'IsContextOK' ");
            return false;
        }

        public override bool IsNewContextOK(Context newCtx) {
            Console.WriteLine("Call 'DemoContextAttribute' - 'IsNewContextOK' ");
            return base.IsNewContextOK(newCtx);
        }
    }

    [DemoContext]
    public class DemoContextBoundObject : ContextBoundObject {
        public DemoContextBoundObject() {
            Console.WriteLine("Call 'DemoContextBoundObject' - 'Constructor' ");
        }
    }

    class Program {
        static void Main(string[] args) {
            Console.WriteLine("Begin Main ");
            new DemoContextBoundObject();
            Console.WriteLine("End Main ");
            Console.Read();
        }
    }
}

执行的结果显示如下：

这里可能以看出在执行的过程中，先建立与ContextBoundObject相关的ContextAttribute对象。并且向ContextAttribute对象询间IsContextOK，环境怎么样还可以吗。这里我先从这个IsContextOK开始进行分析。
这里通过修改代码查看运行的结果发现IsContextOk返回的结果为False,表示对当前环境有点不满意啊，将这里的IsContextOK直接返回True会是什么情况呢。修改代码执行显示结果如下：

 public override bool IsContextOK(Context ctx, IConstructionCallMessage ctorMsg) {
            Console.WriteLine("Call 'DemoContextAttribute' - 'IsContextOK' ");
            return true;
        }

看来这个方式就是用来确认当前环境是否满足要求的，如果满足则不执行。这里可以查看一下这一部分的过程：
   CRL先询问当前环境是否满足要求，如果满足则不继续执行，如果不满足则先初始化新环境的GetPropertiesForNewContext，再将其Freeze，再询问IsNewContextOK如果没有问题则成功，如果在这里返回false，将引发一个Remoting的异常。

 

出处：https://www.cnblogs.com/jeffwoot/archive/2008/05/19/1202427.html

=======================================================================================

昨天了解了ContextAttribute与ContextBoundObject应用开发的一些基础,今天准备在ContextBoundObject对象之上加入消息拦截器,来测试一下应用。
 经过昨天了学习了解到ContextAttribute与ContextBoundObject这一组对象之间的核心关系为：
   IContextAttribute：用于标识上下文环境相关Attribute，当CLR在创建MarshalByRefObject对象时会先查看对象是否包括:IContextAttribute特性，如果存在则询问IContextAttribute.IsContextOK来查询是否需要新的上下文环境，如果返回false则表示需要创建新的上下文环境，并且调用GetPropertiesForNewContext来设计新环境的属性。
   IContextProperty：用于标识上下文环境的属性，可以在GetPropertysForNewContext向新的上下文环境中添加新的自定义属性。
   IContributeObjectSink：如果需要向上下文环境中添加自定义的消息拦截器，由需要IContextProperty的实现对象同时实现本接口。
   还有更多的XXXObjectSink：如果实现也实现相应的消息接收，这里暂不考虑。
注意：如果IContextAttribute附加的对象没有继承自MarshalByRefObject则附加的IContextAttribute会与普通特性一样，不会产生新的上环境文环境。
   了解这一核心关系后，再回过来看昨天所编写的代码，发现其实ConextAttribute已实现IContextAttribute, IContextProperty两个接口。这里所需要添加的只是需要DemoContextAttribute实现IContributeObjectSink接口，并且添加新的消息拦截器。修改后的代码为：

using System;
using System.Collections.Generic;
using System.Text;
using System.Runtime.Remoting.Contexts;
using System.Runtime.Remoting.Activation;
using System.Runtime.Remoting.Messaging;

namespace ContextDemo {
    public class DemoContextAttribute : ContextAttribute, IContributeObjectSink {
        public DemoContextAttribute()
            : base("DemoContextAttribute") {
            Console.WriteLine("Call 'DemoContextAttribute' - 'Constructor' ");
        }

        public IMessageSink GetObjectSink(MarshalByRefObject obj, IMessageSink nextSink) {
            Console.WriteLine("Call 'DemoContextAttribute' - 'GetObjectSink' ");

            return new DemoMessageSink(nextSink);
        }
    }

    public class DemoMessageSink : IMessageSink {
        public DemoMessageSink(IMessageSink nextSink) {
            Console.WriteLine("Call 'DemoMessageSink' - 'Constructor' ");
            this.nextSink = nextSink;
        }

        public IMessageCtrl AsyncProcessMessage(IMessage msg, IMessageSink replySink) {
            // 暂不考虑
            return null;
        }

        private IMessageSink nextSink = null;
        public IMessageSink NextSink {
            get { return nextSink; }
        }

        public IMessage SyncProcessMessage(IMessage msg) {
            Console.WriteLine("Call Begin 'DemoMessageSink' - 'SyncProcessMessage' ");

            IMessage returnMsg = nextSink.SyncProcessMessage(msg);
            Console.WriteLine("Call End 'DemoMessageSink' - 'SyncProcessMessage' ");

            return returnMsg;
        }
    }

    [DemoContext]
    public class DemoContextBoundObject : ContextBoundObject {
        public DemoContextBoundObject() {
            Console.WriteLine("Call 'DemoContextBoundObject' - 'Constructor' ");
        }

        public void CallMethod() {
            Console.WriteLine("Call 'DemoContextBoundObject' - 'Call Method' ");
        }
    }

    class Program {
        static void Main(string[] args) {
            Console.WriteLine("Begin Main ");
            new DemoContextBoundObject().CallMethod();
            Console.WriteLine("End Main ");
            Console.Read();
        }
    }
}

执行后的结果为

查看结果了解到，获取消息拦截器的操作是在调用方法操作后才进行了，那么如果我在这里调用两次操作，是否会产生两次获取消息消息拦截器的操作呢。这里我将Main()操作修改如下：

 static void Main(string[] args) {
            Console.WriteLine("Begin Main ");
            DemoContextBoundObject dcbo = new DemoContextBoundObject();
            dcbo.CallMethod();
            dcbo.CallMethod();
            Console.WriteLine("End Main ");
            Console.Read();
        }

显示的结果如下：

 这里可以看出只调用了一次获取消息拦截器的操作，多次SyncProcessMessage方法的调用，这个同样适用多方法，可以自行再添加一个CallMethod2方法进行测试，效果是一样的。

那么我又想如果这里生成两个对象并且调用同一个方法又会产生什么结果呢。Main()方法修改如下：

static void Main(string[] args) {
            Console.WriteLine("Begin Main ");
            new DemoContextBoundObject().CallMethod();
            new DemoContextBoundObject().CallMethod();
            Console.WriteLine("End Main ");
            Console.Read();
        }

最后的结果显示为：

和想像中的一样，调用了两次生成Sink的过程。

我又想如果在消息拦截的过程中引发了异常将会也现什么总是呢。于是我再次DemoObjectSink的代码修改如下：

   public IMessage SyncProcessMessage(IMessage msg) {
            Console.WriteLine("Call Begin 'DemoMessageSink' - 'SyncProcessMessage' ");
            throw new Exception("I'm a exception");
            IMessage returnMsg = nextSink.SyncProcessMessage(msg);
            Console.WriteLine("Call End 'DemoMessageSink' - 'SyncProcessMessage' ");
            return returnMsg;
        }

并且将Main()的代码修改如下：

 static void Main(string[] args) {
            Console.WriteLine("Begin Main ");
            try {
                new DemoContextBoundObject().CallMethod();
                Console.WriteLine("End Main ");
            }
            catch (Exception ex) {
                Console.WriteLine("Raise Exeption Message:{0}", ex.Message);
            }
            Console.Read();
        }

执行的结果如下：

这里可以发现执行的结果与在方法中执行时产生异常的形式是相同的，已是我就要如果用这种方式来进行安全检查会不会得以实现呢?

 

出处：https://www.cnblogs.com/jeffwoot/archive/2008/05/20/1203174.html

======================================================================================= 

昨天在了解使用ContextAttribuet与ContextBoundObject的过程中发现很多人说MarshalByRefObject使用起来很慢并且有可能会在后面的.NET中不支持。我想这里确实是应当注意的一个问题，但其实可以发现包括ADO.NET中的对象大多数对象都是继续于MarshalByRefObject对象，如果MS在这种对象上使用都没有性能上的问题，我想在Domain层之中使用这种也应当不会产生性能的问题，一个系统的总体性能不应当是只靠这一点就起了吧。并且如果.NET后面不支持，我想它也会想好一个更好的方法吧。

 

出处：https://www.cnblogs.com/jeffwoot/archive/2008/05/20/1203182.html