如何實現對上下文（Context）數據的統一管理 [提供源代碼下載]

在應用開發中，我們經常需要設置一些上下文（Context）信息，這些上下文信息一般基於當前的會話（Session），比如當前登錄用戶的個人信息；或者基於當前方法調用棧，比如在同一個調用中涉及的多個層次之間數據。在這篇文章中，我創建了一個稱爲ApplicationContext的組件，對上下文信息進行統一的管理。[Source Code從這裏下載]

一、基於CallContext和HttpSessionState的ApplicationContext

如何實現對上下文信息的存儲，對於Web應用來說，我們可以藉助於HttpSessionState；對於GUI應用來講，我們則可以使用CallConext。ApplicationContext完全是藉助於這兩者建立起來的，首先來看看其定義：

using System;

using System.Collections.Generic;

using System.Runtime.Remoting.Messaging;

using System.Web;

namespace Artech.ApplicationContexts

{

    [Serializable]

    public class ApplicationContext:Dictionary<string, object>

    {

        public const string ContextKey = "Artech.ApplicationContexts.ApplicationContext";

        

        public static ApplicationContext Current

        {

            get

            {

                if (null != HttpContext.Current)

                {

                    if (null == HttpContext.Current.Session[ContextKey])

                    {

                        HttpContext.Current.Session[ContextKey] = new ApplicationContext();

                    }

  

                    return HttpContext.Current.Session[ContextKey] as ApplicationContext;

                }

  

                if (null == CallContext.GetData(ContextKey))

                {

                    CallContext.SetData(ContextKey, new ApplicationContext());

                }

                return CallContext.GetData(ContextKey) as ApplicationContext;                

            }

        }        

    }

}

爲了使ApplicationContext定義得儘可能地簡單，我直接讓它繼承自Dictionary<string,object>，而從本質上講ApplicationContext就是一個基於字典的上下文數據的容器。靜態屬性Current表示當前的ApplicationConext，如何當前存在HttpContext，則使用HttpConext的Session，否則使用CallConext。Session和CallConext的採用相同的Key：Artech.ApplicationContexts.ApplicationContext。你可以採用如下的方式對上下文數據進行設置和讀取。

//設置

ApplicationContext.Current["UserName"] = "Foo";

//讀取

var userName = ApplicationContext.Current["UserName"];

二、ApplicationContext在異步調用中的侷限

在同步調用的情況下，ApplicationContext可以正常工作。但是對於異步調用，當前的上下文信息並不能被傳播到另一個線程中去。接下來，我們將給出一個簡單的例子，模擬通過ApplicationContext存貯用戶的Profile信息，爲此，我定義瞭如下一個Profile類，屬性FirstName、LastName和Age代表三個Profile屬性。

using System;

namespace Artech.ApplicationContexts

{

    [Serializable]

    public class Profile

    {

        public string FirstName

        { get; set; }

        public string LastName

        { get; set; }

        public int Age

        { get; set; }

        public Profile()

        {

            this.FirstName = "N/A";

            this.LastName = "N/A";

            this.Age = 0;

        }

    }

}

爲了便於操作，我直接在ApplicationContext定義了一個Profile屬性，返回值類型爲Profile，定義如下：

[Serializable]

public class ApplicationContext : Dictionary<string, object>

{

    public const string ProfileKey = "Artech.ApplicationContexts.ApplicationContext.Profile";   

  

    public Profile Profile

    {

        get

        {

            if (!this.ContainsKey(ProfileKey))

            {

                this[ProfileKey] = new Profile();

            }

            return this[ProfileKey] as Profile;

        }

    }

}

現在我們來看看ApplicationContext在一個簡單的Windows Form應用中的使用情況。在如右圖（點擊看大圖）所示的一個Form中，我們可以進行Profile的設置和獲取。其中“Get [Sync]”和“Get [Async]”按鈕分別模擬對存貯於當前ApplicationContext中的Profile信息進行同步和異步方式的獲取，通過點擊Save按鈕將設置的Profile信息保存到當前的ApplicationContext之中。

“Save”、“Clear”、“Get [Sync]”和“Get [Async]”響應的事件處理程序如下面的代碼所示：

using System;

using Artech.ApplicationContexts;

namespace WindowsApp

{

    public partial class ProfileForm : System.Windows.Forms.Form

    {

        public ProfileForm()

        {

            InitializeComponent();

        }

  

        private void buttonSave_Click(object sender, EventArgs e)

        {

            ApplicationContext.Current.Profile.FirstName = this.textBoxFirstName.Text.Trim();

            ApplicationContext.Current.Profile.LastName = this.textBoxLastName.Text.Trim();

            ApplicationContext.Current.Profile.Age = (int)this.numericUpDownAge.Value;

        }

  

        private void buttonClear_Click(object sender, EventArgs e)

        {

            this.textBoxFirstName.Text = string.Empty;

            this.textBoxLastName.Text = string.Empty;

            this.numericUpDownAge.Value = 0;

        }

  

        private void buttonSyncGet_Click(object sender, EventArgs e)

        {

            this.textBoxFirstName.Text = ApplicationContext.Current.Profile.FirstName;

            this.textBoxLastName.Text = ApplicationContext.Current.Profile.LastName;

            this.numericUpDownAge.Value = ApplicationContext.Current.Profile.Age;

        }

  

        private void buttonAsyncGet_Click(object sender, EventArgs e)

        {

            GetProfile getProfileDel = () =>

                {

                    return ApplicationContext.Current.Profile;

                };

            IAsyncResult asynResult = getProfileDel.BeginInvoke(null, null);

            Profile profile = getProfileDel.EndInvoke(asynResult);

            this.textBoxFirstName.Text = profile.FirstName;

            this.textBoxLastName.Text = profile.LastName;

            this.numericUpDownAge.Value = profile.Age;

        }

  

        delegate Profile GetProfile();       

    }

}

運行上面的程序，你會發現你設置的Profile信息，可以通過點擊“Get [Sync]”按鈕顯示出來，。而你點擊“Get [Async]”按鈕的時候，卻不能顯示正確的值。具體的結果如下圖（點擊看大圖）所示。三張截圖分別模擬的點擊“Save”、Get [Sync]”和“Get [Async]”按鈕之後的顯示。

上面演示的是ApplicationContext在Windows Form應用中的使用，實際上在ASP.NET應用中，你依然會得到相同的結果。通過ApplicaticationContext的定義我們可以知道，ApplicationContext對象最終保存在CallContext或者HttpSessionState中。Windows Form應用採用的是前者，而Web應用則採用後者。

也就是說，無論是CallContext還是HttpContext（HttpSessionState最終依附於當前的HttpContext），都不能自動實現數據的跨線程傳遞。至於原因，需要從兩種不同的CallContext說起。

三、LogicalCallContext V.S. IllogicalCallContext

CallContext定義在System.Runtime.Remoting.Messaging.CallContext命名空間下，是類似於方法調用的線程本地存儲區的專用集合對象，並提供對每個邏輯執行線程都唯一的數據槽。數據槽不在其他邏輯線程上的調用上下文之間共享。當 CallContext 沿執行代碼路徑往返傳播並且由該路徑中的各個對象檢查時，可將對象添加到其中。CallContext定義如下：

[Serializable, ComVisible(true), SecurityPermission(SecurityAction.LinkDemand, Flags = SecurityPermissionFlag.Infrastructure)]

public sealed class CallContext

{

    

    public static void FreeNamedDataSlot(string name);

    public static object GetData(string name);

    public static Header[] GetHeaders();    

    public static object LogicalGetData(string name);

    public static void LogicalSetData(string name, object data);

    public static void SetData(string name, object data);

    public static void SetHeaders(Header[] headers);

   

    public static object HostContext { get; [SecurityPermission(SecurityAction.LinkDemand, Flags = SecurityPermissionFlag.Infrastructure)] set; }   

}

CallContext具有如下兩種不同的類型：

LogicalCallContext：LogicalCallContext 類是在對遠程應用程序域進行方法調用時使用的 CallContext 類的一個版本。CallContext 是類似於方法調用的線程本地存儲的專用集合對象，並提供對每個邏輯執行線程都唯一的數據槽。數據槽不在其他邏輯線程上的調用上下文之間共享。當 CallContext 沿執行代碼路徑往返傳播並且由該路徑中的各個對象檢查時，可將對象添加到其中。當對另一個 AppDomain 中的對象進行遠程方法調用時，CallContext 類將生成一個與該遠程調用一起傳播的 LogicalCallContext。只有公開 ILogicalThreadAffinative 接口並存儲在 CallContext 中的對象被在 LogicalCallContext 中傳播到 AppDomain 外部。不支持此接口的對象不在 LogicalCallContext 實例中與遠程方法調用一起傳輸。
IllogicalCallContext：IllogicalCallContext和LogicalCallContext 相反，僅僅是存儲與當前線程的TLS中，並不能隨着跨線程的操作執行實現跨線程傳播。

HttpContext本質上也通過CallContext存儲的，不過HttpContext本身是作爲IllogicalCallContext的形式保存在CallContext，這也正是爲何基於HttpSessionState的ApplicationContext也不能解決多線程的問題的真正原因。

四、讓CallContext實現跨線程傳播

也就是說，如果想讓CallContext的數據被自動傳遞當目標線程，只能將其作爲LogicalCallContext。我們有兩種當時將相應的數據存儲爲LogicalCallContext：調用CallContext的靜態方法LogicalSetData，或者放上下文類型實現ILogicalThreadAffinative接口。

也就說，在ApplicationContext的Current方法中，我們只需要將CallContext.SetData(ContextKey, new ApplicationContext());替換成CallContext.LogicalSetData(ContextKey, new ApplicationContext());即可：

[Serializable]

public class ApplicationContext : Dictionary<string, object>

{

    //其他成員

    public static ApplicationContext Current

    {

        get

        {

            //...

            if (null == CallContext.GetData(ContextKey))

            {

                CallContext.LogicalSetData(ContextKey, new ApplicationContext());

            }

            return CallContext.GetData(ContextKey) as ApplicationContext;

        }

    }

}

或者說，我們直接讓ApplicationContext實現ILogicalThreadAffinative接口。由於該ILogicalThreadAffinative沒有定義任何成員，所有我們不需要添加任何多餘的代碼：

[Serializable]

public class ApplicationContext : Dictionary<string, object>, ILogicalThreadAffinative

{

    //...

}

現在再次運行我們上面的Windows Form應用，點擊“Get [Async]”按鈕後將會得到正確的Profile顯示，有興趣的讀者不妨下載實例代碼試試。但是當運行Web應用的時候，依然有問題，爲此我們需要進行一些額外工作。

五、通過ASP.NET擴展解決Web應用的異步調用問題

在上面我們已經提過，ASP.NET管道將當前的HttpContext的存儲與基於當前線程的CallContext中，而存貯的形式是IllogicalCallContext而非LogicalCallContext，說在非請求處理線程是獲取不到當前HttpContext的。針對我們ApplicationContext就意味着：在Web應用中，主線程實際上操作的是當前HttpContext的Session，而另外一個線程中則是直接使用CallConext。

那麼如果我們們能夠將存儲與當前HttpContext的Session中的ApplicationContext作爲LogicalCallContext拷貝到CallContext中，那麼在進行異步調用的時候，就能自動傳遞到另外一個線程之中了。此外，由於ASP.NET採用線程池的機制處理HTTP請求，我們需要將當前CallContext的數據進行及時清理，以免被另外一個請求複用。我們可以有很多方式實現這樣的功能，比如在Global.asax中定義響應的事件處理方法，自定義HttpApplication或者自定義HttpModule。

如果自定義HttpModule，我們可以註冊HttpApplication的兩個事件：PostAcquireRequestState和PreSendRequestContent，分別實現對當前ApplicationContext的拷貝和清理。具體定義如下：

using System.Runtime.Remoting.Messaging;

using System.Web;

namespace Artech.ApplicationContexts

{

    public class ContextHttpModule:IHttpModule

    {

  

        public void Dispose(){}

        public void Init(HttpApplication context)

        {

            context.PostAcquireRequestState += (sender, args) =>

                {

                    CallContext.SetData(ApplicationContext.ContextKey, ApplicationContext.Current);

                };

            context.PreSendRequestContent += (sender, args) =>

            {

                CallContext.SetData(ApplicationContext.ContextKey, null);

            };

        }

    }

}

我們只需要通過如下的配置將其應用到我們的程序之中即可：

<?xml version="1.0"?>

<configuration>

  <system.web>

    <httpModules>

      <add name="ContextHttpModule" type="Artech.ApplicationContexts.ContextHttpModule,Artech.ApplicationContexts.Lib"/>

    </httpModules>

  </system.web> 

</configuration>

如何實現對上下文（Context）數據的統一管理

如何實現對上下文（Context）數據的統一管理 [提供源代碼下載]

一、基於CallContext和HttpSessionState的ApplicationContext

二、ApplicationContext在異步調用中的侷限

爲了便於操作，我直接在ApplicationContext定義了一個Profile屬性，返回值類型爲Profile，定義如下：

三、LogicalCallContext V.S. IllogicalCallContext

CallContext具有如下兩種不同的類型：

四、讓CallContext實現跨線程傳播

或者說，我們直接讓ApplicationContext實現ILogicalThreadAffinative接口。由於該ILogicalThreadAffinative沒有定義任何成員，所有我們不需要添加任何多餘的代碼：

現在再次運行我們上面的Windows Form應用，點擊“Get [Async]”按鈕後將會得到正確的Profile顯示，有興趣的讀者不妨下載實例代碼試試。但是當運行Web應用的時候，依然有問題，爲此我們需要進行一些額外工作。

五、通過ASP.NET擴展解決Web應用的異步調用問題

HTML頁面關於高分屏的設置

北歐瑞典挪威芬蘭瑞士TikTok海外網紅與YouTube博主的合作模式

歐洲英國德國法國TikTok與YouTube海外網紅達人的完美合作策略

druid數據源 xml配置

如何實現對上下文（Context）數據的統一管理

酒店項目OO設計

javascript 替換字符串中回車符

學習和分享一點簡單的System.Web.HttpRuntime.Cache的使用經驗

（SQL）如何將exec執行結果放入外面的變量中－－動態sql

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結