我們經常為調用不同的功能時顯式建立不同的業務類進行調用,這種調用關係是緊密依賴的;很多時候採用原廠模式來進行分離.基於訊息的應用程式框架就是採用原廠模式的原理並細化.在際實工作中開發人員並不需瞭解有那些業務功能類,只需要向業務容器發送相應功能的訊息;業務容器收到訊息後會進行分析並啟動執行相關的業務功能.由於訊息和業務類是分離描述的,所以可以很方便地在不改變原有代碼的情況插入新的功能.架構還織入了內容物件,交易處理用於解決了對象資訊共用和事務問題,從而使開發人員有更多的精力在業務功能設計上.
架構主要由以下幾部份組成:
訊息(IMessage)
在架構中訊息是用於描述需要做什麼,可以說是訊息處理容器的一條指命;定義一條自己的訊息只需要實現架構的IMessage介面; IMessage介面並沒有任何成員,只是用於標識是架構處理的訊息.
public class BusinessMessage:Messages.IMessage
{
}
訊息處理容器(DispenseContainer)
容器是用於接收訊息和分發處理.容器只有一個切入點用於接收訊息處理完成後返回訊息給調用對象.
Messages.DispenseContainer container = Messages.DispenseContainer.OpenConfig();
Messages.IMessage msg = container.Incept(new BusinessObjects.BusinessMessage());
訊息和業務對象關係描述(MessageSectionHandler)
架構是以XML設定檔的方式來描述訊息和業務對象之間的關係.可以任意為訊息類型配置一個或多個業務對象.
<message type="類型名稱,程式集" transaction="訊息處理通道是否具備事務功能">
<export type="類型名稱,程式集" single="是否單一執行個體化"/>
…
</message>
內容物件(MessageContext)
內容物件可以很好地解決對象之間資訊共用的問題,只要業務對象在訊息通道裡執行就可以得到該對象的訪權.
public class BObject1:Messages.IDispense
{
#region IDispense Members
Messages.IMessage Messages.IDispense.Export(Messages.IMessage message)
{
if (Messages.MessageContext.Current.Properties.Contains("name"))
{
Messages.MessageContext.Current.Properties["name"] =
Messages.MessageContext.Current.Properties["name"] + "\n\r" + this.ToString();
}
else
{
Messages.MessageContext.Current.Properties["name"] = this.ToString();
}
Console.Write(Messages.MessageContext.Current.Properties["name"]+"\n");
return new Counter();
}
#endregion
}
交易處理
架構對訊息通道整合了交易處理能力,可以在訊息和業務對象關係描述裡設定該類型的訊息通道是否具備事務能力;如果具備事務,在通道裡所有業務對象都會運行在事務環境中.事務由COM+提供,對於業務對象存在無狀態調用時是得不到事務的保證(如果調WebService等)
架構類圖描述
架構還在設計階段,有些功能還不具備,這麼早公布出來主要是想大家提下意見和想法.
相關案例和源碼