實現客戶端 ??????當一個基于CLR?組件服務類被編譯和部署，你就需要在客戶端調用它。長遠來看，組件服務類沒什么特別之處;事實是使用COM+?運行時服務是不相關的。?這個代碼展示了簡單類早期的定義MyTxCfgClass: using ESExample; public class Client { ?public static void Main(string[] args) ?{ ??? MyTxCfgClass tcc = new MyTxCfgClass(); ????... // use object as desired ?} } ??????當然，與所有的CLR代碼，客戶端必須引用組件服務類程序集。 csc /r:ESExample.dll Client.cs 細微的復雜性 ??????這里你會看到，服務類通過?.NET CLR實現COM+是相當的容易。?System.EnterpriseServices?命名空間里的類提供了可以使用COM+運行時服務的API。運行時服務本身沒什么改變；他們工作的方式還是?COM+開發者熟知的。已經說了，?集成COM+和CLR?沒有涉及到如此細微的復雜性。?有幾個問題是使得使用CLR語言寫?COM+?代碼比我剛才提到的復雜的多。?有些問題會產生，因為CLR畢竟不是?COM，?因為它可以做COM做不到的事情。這些問題是不能解決的;?你只要知道如何CLR的特性如靜態方法和垃圾回收器?如何影響COM+?編程。
??????再學習這些問題前，你必須知道CLR?的類和?and COM+?上下文環境的關系。?首先，調用繼承自ServicedComponent的類的實例都會被COM+?上下文環境邊界偵聽。這些對象稱為上下文環境邊界。調用沒繼承自ServicedComponent的類的實例就不會被上下文環境邊界偵聽。?這些對象稱為context-agile。CLR對象默認就是context-agile。?當你繼承自ServicedComponent它們會變成context-bound?。(這個與?.NET remoting?上下文環境沒有關系，我下面會講到。)?圖?9說明的這個架構

圖?9?上下文環境對象 ?????非常有趣的是CLR?對象可以實現類似COM?對象和COM+?上下文環境交互這樣的行為。通過?COM，調用對象通常默認都會被偵聽;?所有的對象都是context-bound。COM?對象是context-agile?只有當它聚集了freethreaded marshaler (FTM)且不是第一個在COM+?上下文環境里?被創建的對象(因為它不是可識別的對象)，?這樣情況下，調用不會被偵聽。?新方法確保調用真的需要的時候被預處理和遲處理的好處是減少了偵聽負荷。?特別地，如果組件服務類的實例返回了一個非組件服務類的實例?(例如一個?ADO.NET DataSet?對象)，這個調用不會被偵聽。?并且DataSet對象不需要做任何事情，它就是照常工作。 ??????第二個你應該知道的事情是，?除了減少真正需要的交叉上下文偵聽外，?CLR/COM+集成盡可能地避免了托管類型和自有類型間的轉換。?來自托管的CLR?代碼到COM的調用是比較昂貴的。重要的部分就是類型的前后轉換—大部分在CLR strings和COM BSTRs之間。?請求穿過COM+環境邊界需要?調用一些固有的代碼，?組件已經相當聰明可以避免同樣來自CLR且處在同一進程里的調用者和被調用者之間的類型轉換。?或許有一天所有的COM+?運行時服務都會用CLR語言重新實現，調轉就不成問題了。?那時不管如何，這個優化都會使得COM+?偵聽更加快速。 靜態方法和屬性 ??????現在你知道了CLR代碼如何關聯上下文環境，?思考這個問題：如果一個基于CLR?組件服務類?包括靜態方法和屬性訪問器，?它將在什么上下文里執行呢？答案是調用者。?這個看起來不是很直觀，?但是它確實很有意義當你想靜態成員不是對象定義且不許要在對象駐留的上下文里訪問。例如，組件服務類在圖?10有個靜態方法，2，?和靜態屬性，4。這個代碼會在調用者的上下文里執行。?調用實例的方法1，?或者屬性3，通常在對象的上下文里執行。 ?????這時你或許想知道當你在屬性里保存了一個對象的靜態引用且你想在另外一個上下問里引用會發生什么事情。基于COM的COM+編程里，?在被成為靜態屬性的全局變量里保存了一個原始的對象引用，?會導致嚴重的錯誤因為你不可以把對象不加包裝地從原來的上下文里帶走。使用基于CLR COM+?代碼，?這個就不是一個問題。?CLR?使用相當瘦的代理包裝了每個組件服務類的實例子這樣其它上下問的對象就不需要保留對象的直接引用。如果代碼在一個保留基于CLR?組件服務類引用在靜態屬性的的上下文執行。它實際保留的是一個引用。如果另一個上下文里的代碼要通過靜態屬性訪問它，?特定的代理就發現變化而且封裝它自己保留的引用這樣偵聽就觸發了。這個是有個優美的解決方案，本質上你可以任何地方保存基于CLR服務類的實例并且都會正確觸發。 ????? 管理珍貴的資源 ?????我現在開始另外一個管理對象引用的話題'，另外一個問題你必須注意CLR靠垃圾收集器回收內存。?這是個重要的事情因為它要自動幫助避免內存泄露并且釋放閑置的內存。非常不幸的是，?垃圾收集器使得內存管理變的容易，但是他同樣帶來了其他問題，比如管理COM+設計的對象變的困難。因此高效地管理資源是建立可伸縮的系統的關鍵，這正是COM+?的設計目標，你需要知道如果合理地釋放基于CLR的資源。 ?????考慮?CLR類使用到了SqlConnection?對象連接數據庫，?如下所示: public void UseADatabase(void) { ?System.Data.SqlClient.SqlConnection = ????? new System.Data.SqlClient.SqlConnection(…); ??? …// use connection to execute statements } 在UseADatabase方法的結束部分，?SqlConnection?對象被釋放。?SqlConnection對象封裝了處理數據庫的連接并且為了效率考慮被ADO.NET底層機制池化(Beta 1?使用COM+?對象池; Beta 2，?使用了類似COM+?對象池的機制)。?問題是?SqlConnection對象管理的連接何時歸還到對象池??不等垃圾收集器進入，就意識到SqlConnection?對象不在被使用，就調用終結器。finalizer?把連接歸還給對象池，?然后SqlConnection對象的內存就被回收。 ??????問題是數據庫連接資源是非常珍貴的資源，你不能讓他們無約束地飄蕩在內存里，直到垃圾收集器來回收。?需要一些方法來回收這樣的資源。一種方式就是強制垃圾收集器執行回收工作，如下所示: public void UseADatabase(void) { ?System.Data.SqlClient.SqlConnection conn = ????? new System.Data.SqlClient。SqlConnection(…); ?… // use connection to execute statements ?conn = null; ?System.GC.Collect();??? } 然而，這個方法相當的笨拙且有很多潛在問題。 ?????更好的方法是調用SqlConnection?對象實現的接口的?IDisposable.Dispose方法。?IDisposable?接口在System命名空間，它規范擁有昂貴的要清理的資源的對象通過客戶端定義操作釋放資源代理垃圾收集器回收的行為。SqlConnection實現了Dispose，快速歸還對象給對象池?(事實上和調用finalizer的作用一樣)。 ??????下面代碼是新版本的UseADatabase方法，它顯示的清除了SqlConnection。 public void UseADatabase(void) { ?System.Data.SqlClient.SqlConnection conn = ????? new System.Data.SqlClient.SqlConnection(…); ?try ?{ ??? … // use connection to execute statements ?} ?finally ?{ ??? Conn.Dispose(); ?} } 注意到Dispose出現在finally塊里確保它可以執行，不管是否拋出異常。 ??????那這個和COM+與服務類有什么關系呢??首先，你的服務類很可能使用數據庫連接和其它昂貴的資源，?所以如果你希望系統凈化，你就應該知道如果合理地釋放資源。?第二是，?所有基于CLR?服務類?實現了IDisposable.Dispose方法，?因為基類，ServicedComponent。你應該知道當客戶端調用Dispose時發生了什么。默認實現的行為取決于你的組件服務類?使用了什么運行時服務。如果你沒使用對象池激活，?Dispose就會立即調用?finalizer (如果已經被垃圾收集器回收，就不會再調用)。如果你的組件服務類?使用了對象池而不是JIT?激活，?Dispose調用Deactivate去通知對象已經離開它當前的上下文。然后它就調用?CanBePooled?去詢問對象是否重用或銷毀。?如果CanBePooled返回true，?對象會返回到對象池里。?返回false，?對象的finalizer就會調用?(如果已經被垃圾收集器回收，就不會再調用)。?非常重要是客戶端為池化的對象調用方法Dispose，如下所示。 public void UseAPooledObject(void) { ?MyPooledCfgClass pcc = new MyPooledCfgClass(); ?try ?{ ??? …// use pooled object to do something ?} ?finally ?{ ??? Pcc.Dispose(); ?} } ??????如果不調用Dispose，對象?(如描述的數據庫連接)，?只有等到垃圾收集器回收資源。?最后，?如果你自己實現組件服務類的Dispose方法，?你必須調用基類的實現去實現這些描述的行為。 [ Synchronization(SynchronizedOption.Required) ] public class MyCfgClass : ServicedComponent { ?public new void Dispose() ?{ ??? … // do whatever ??? Base.Dispose(); // call base to clean up ?} } ????你或許想知道?JIT?激活和反激活一個對象在方法的結束。?那解決了資源的管理問題了嗎?答案是否。?反激活使得對象在結束調用前釋放自己成員所有的資源，?同樣包括想使用相同資源的的每個方法調用。你可以通過不保存任何資源的方式達到這個目的。如果你沒有選擇?JIT?激活?和反激活在每次方法調用的結尾，?知道客戶端調用Dispose實際上是強制你的對象重激活到飯激活并且重新終結一次。通常情況下，?到CLR的轉換不會改變的JIT?激活規則。?應該避免使用它除非運行時服務需要它?(比如聲明的服務)?因為它不會更高效，?且?比你自己管理昂貴的資源效率低。 展望 ??????ServicedComponent?類繼承自?System。ContextBoundObject，?它又繼承自System。MarshalByRefObject，?這個基類可以使對象可以通過.NET remoting機制?被訪問到。在Remoting頂層?上進行CLR/COM+集成有兩個好處。首先你能通過Remoting層使用SOAP訪問COM+?運行時服務的遠程對象。但是你不能夠使用SOAP傳遞事務到另外的進程?(非你所愿，?但道理如此)。?第二點，打開了新版的新的基于CLR Remoting上下文架構實現的COM+?運行時服務的方式?這是現在的COM+所沒有用到的。?將來一定會夠發生。?真要這樣，服務就可以與SOAP或者其他的傳輸無逢集成，并且上下文就可以真的可以擴展了。那時，?已經正確跨出一大步的CLR?就會使得COM+編程變的更加容易。

相關文章: Windows XP: Make Your Components More Robust with COM+ 1.5 Innovations House of COM: Migrating Native Code to the.NET CLR the "samples"technologies"component服務?subdirectory of the.NET Framework SDK 事務al COM+: Building?可伸縮的應用系統?by Tim Ewald (Addison-Wesley, 2001)

作者Tim Ewald: DevelopMento的首席科學家，?最近出版的?事務性COM+:?創建可伸縮的應用系統?(Addison-Wesley，?2001)的作者 翻譯Frank Xu Lei:程序員，技術博客http://www.cnblogs.com/frank_xl/。

來自10月?2001的?MSDN雜志


?本文轉自 frankxulei 51CTO博客，原文鏈接：http://blog.51cto.com/frankxulei/321005，如需轉載請自行聯系原作者

總結

以上是生活随笔為你收集整理的经典技术文章翻译(1):COM+集成:.NET Enterprise Services 如何帮你建立分布式应用(2)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。