其他

1.緣起：    假設我們的訂單系統需要管理所有未處理的訂單，而客人經常需要查詢屬於自己的未處理的訂單列表。另外，可能客服人員也需要根據訂單ID迅速地找到對應的未處理訂單。基於第一個需求，我們就可以將未處理的訂單依據客人的帳號進行分組管理。    我設計了ESBasic.ObjectManagement.Managers.IGroupingObjectManager分組對象管理器來完成對對象進行分組管理的功能。      分組對象管理器的形象如下：   

自從03年正式使用.NET開發以來，已經走過了6個年頭，這期間我積累了幾套類庫和架構，ESBasic便是其中最基礎的一個類庫。ESBasic是Enterprise Service Basic的縮寫，雖然也簡寫為ESB，但是它和Enterprise Service Bus（企業服務匯流排）沒有任何關係。ESBasic是我能夠快速和高效開發應用程式的利器之一，開這個專門的blog是想將它介紹給大家，希望能對大家有所啟發。ESBasic覆蓋的內容包括：對象管理、外掛程式、網路（Socket）、多線程、

1.緣起：    對象池應該是一個“曆史悠久”的概念了，像我們經常說的線程池、還有ADO.NET中的資料庫連接池等，都屬於對象池的應用。    我們的應用有時也會碰到需要使用對象池的情況，我舉個例子說明一下。假設，我們需要記錄某個類MyClass的每個方法每次被調用時方法執行所消耗的時間，而且，這個類是使用在多線程的環境中的，每個方法都可以同時在多個線程中執行，不需要被同步，這樣可以使並發達到最大。   

   DataRabbit3.0為ORM訪問器提供了批量插入的功能，其方法定義如下：        /// <summary>        /// BatchInsert 批量插入一組記錄。忽略所有Blob欄位。        /// </summary>               void BatchInsert(IList<EntityType> entityList);    當我們需要一次性向同一Table中插入大量（如千條以上）的記錄時，使用Ba

1.緣起：    為了提升系統的效能或減輕資料庫的壓力等原因，我們經常在系統中使用緩衝來把那些經常使用的資料保留在記憶體中。如果因為某些原因，緩衝中這些經常使用的資料不能及時與資料來源進行同步更新，那麼採用定時重新整理緩衝中的資料有可能就是一種合適的選擇。    如果你的緩衝是定時重新整理，那麼你就需要自己為其維護一個定時器或迴圈引擎。如果你的系統中像這樣定時重新整理的緩衝有多個，而且每個緩衝定時重新整理的時間間隔又要求不一樣，那麼，使這些緩衝按照你預想的情況進行運轉，你就需要花費一些氣力。  

1.緣起：    假設我們的會員管理系統有一個熱門排行榜的功能，需要每隔一段時間就對系統中的所有會員（假設會員數有100萬）的積分進行排序，然後對其中的前100名進行某些獎勵。    這是一個典型的TopN演算法――對巨大數量的對象進行排序，然後只需要取出最Top的前N名（N比對象總數小很多），作為熱門排行榜的資料。    解決這樣的問題，我們要注意一點，如果我們每次都對所有的對象進行完全排序，那無疑效率非常低下，而且非常不划算。因為我們只需要前N名，而不是所有對象的先後順序。   

     最新版本的DataRabbit（版本號碼：V3.2）新增一項重要功能－－可以捕獲訪問資料庫時產生的異常的詳細資料，包括：異常對象、Sql語句、sql參數的名稱和值。這是由IDBOperationLogger介面提供支援的。Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-->   

   今天裝好了VS2008 Beta2，就迫不及待地試用一下Linq中的ORM功能，在初步嘗試後，發現Linq中的ORM還是非常不錯的，通過反射查看System.Data.Linq.dll發現，Linq中的ORM是使用反射完成了OR的映射工作，基於此，我開始有點懷疑Linq中的ORM的效能問題。為了進一步研究問題，我寫了一個簡單的測試，在事務中，使用DataRabbit 3.0和 Linq to sql 以ORM的方式分別向資料庫的Customer表中插入1000條資料，來看各自所需的時間。 

   在目前的工作中需要解決複製整個SqlServer資料庫的問題，複製的內容包括資料庫大綱、資料庫中的預存程序、函數、表結構、主外鍵關係以及表中的所有資料等，也就是說copy版本與原資料庫一模一樣。經過一段時間的摸索，找到的一個比較簡單的解決方案是：（1）在複製資料庫之前，先備份該資料庫到檔案。（2）依據備份檔案建立新的資料庫，並Restore即可。   備份資料庫可用如下Sql語句：string.Format("backup database {0} to disk = '{1}';", d

   （完全限定類名：DataRabbit.Schema.IDataSchemaAccesser）   在前面介紹的很多訪問器的實現中，都不需要使用者提供任何關於資料庫表結構的資訊（比如，主鍵、主外鍵關係等），這是因為它們都藉助於IDataSchemaAccesser來擷取目標資料表的大綱資訊，本文就來介紹如何使用DataRabbit架構中的IDataSchemaAccesser來訪問和操作資料表的大綱。   我們可以從DataRabbit的進入點IDataAccesser中擷取IDataSch

   DataRabbit 3.0重寫了DataRabbit 2.0的ORM實現的核心，效能提升了90倍左右，結果是DataRabbit 3.0的ORM效能與直接使用ADO.NET的效能已經非常接近。這是如何做到的？   主要是基於兩點：（1）DataRabbit 2.0 基於泛型和反射實現，而DataRabbit 3.0 基於泛型和Emit動態程式集實現。   DataRabbit 2.0使用反射機制將值在O和R之間傳遞，如此大量使用反射會使效能折損不少。DataRabbit 3.0在運行時，

1.緣起：ESBasic中許多管理對象的容器都用到了這個ESBasic.ObjectManagement.IObjectRetriever介面，所以單獨將其提出來介紹一下。當我們向對象容器（Container）請求某個對象時，也許目標對象還未載入到容器中，這可能是因為容器在初始化的時候就沒有載入這個對象，也有可能是因為這個對象是容器初始化以後新增到資料庫（當然也有可能是其它的持久化儲存）的。在這種情況下，對象容器就可以藉助IObjectRetriever來將目標對象從資料庫等持久化儲存中載入到容

  （完全限定類名：DataRabbit.ORM.IEntityRelationLoader）   在DataRabbit架構提供的ORM功能之中，除了IOrmAccesser介面展現的核心ORM功能外，IEntityRelationLoader介面也提供了一些有意義的功能。正如其名，IEntityRelationLoader是通過資料表的主外鍵關係來載入當前Entity的Parent和Children。   現在對我們前面樣本經常用到的Student資料表做個擴充，假設，Student表的Me

      在高並發的系統中，我們常採用多資料庫分散放置、讀寫分離、細粒度的隔離等級設定等策略來提高系統的效能。DataRabbit3.3

1.緣起：   假設我們有一個會員管理系統，需要向各方提供查詢會員基礎資料的功能。會員一經註冊，其基礎資料就將不再發生變化（如會員帳號、身份證ID、註冊時間等等）。   基於這樣的需求，我們可以將會員的基礎資料“永久地”緩衝在記憶體中，從而提升對任何一個會員基礎資料的查詢速度。   我設計了ESBasic.ObjectManagement.Cache.ISmartDictionaryCache來對這種性質的對象進行緩衝。   

   在我的架構經驗小結（三）－－

1.緣起：    假設我們有一個訂單系統，現在這個系統要增加一個功能――允許客人查核他認為有問題的訂單的詳細資料。當客人覺得自己的某個訂單不對勁時，他首先會從訂單系統查詢這個訂單的詳細資料，然後打電話告訴我們的客服有問題的訂單的編號，客服再去查核，如果屬實，客服還要進一步上報，如果該訂單非常重要，則可能需要更進一步上報複查等。    從這個需求我們看到，同一個訂單可能會在比較短的時間內查詢數次甚至數十次，所以我們可以稱這個訂單為“熱點”訂單。而其它的成千上萬的訂單可能在一個月內都不被查詢一次。 

     在DataRabbit 輕量的資料訪問架構（12）－－ 將DataRabbit融入架構

    在許多項目應用中，我們設計的資料庫中的一些表中的資料變化的頻率很慢，比如，我們有個GameInformation表儲存所有已上線的遊戲的資訊，這個表中的資料變動的頻率就很小（因為可能一兩個月才會有個新遊戲上線或偶爾修改一下已上線遊戲的具體資訊（通常都是不需緊急更新的）），而且，這個表中的資料又經常被用到，比如根據GameID擷取遊戲的名字、簡介等等。這種表就很適合緩衝在記憶體中，這樣可以提供更好的效能和有效地降低資料庫的負載。    DataRabbit.Application.Cach

   （完全限定類名：DataRabbit.Application.TransactionScopeFactory