\

主要結論

\\

• 如果需要執行基本CURD之外的其他操作，此時就有必要使用倉儲（Repository）。\\t
• 為了促進測試工作并改善可靠性，應將倉儲視作可重復使用的庫（Library）。\\t
• 將安全和審計功能放入倉儲中可減少Bug并簡化應用程序。\\t
• 對ORM的選擇不會限制倉儲的用途，只會影響倉儲承擔的工作量。\

\\

在之前發布的文章使用實體框架、Dapper和Chain的倉儲模式實現策略中，我們介紹了實現倉儲所需的基本模式。很多情況下，這些模式只是圍繞底層數據訪問技術，本質上并非完全必要的薄層。然而通過構建這樣的倉儲將獲得很多新的機會。

\\

在設計倉儲時，需要從“必須發生的事”這個角度來思考。例如，假設制訂了一條規則，每當一條記錄被更新后，其“LastModifiedBy”列必須設置為當前用戶。但我們并不需要在每次保存前更新應用程序代碼中的LastModifiedBy，可以直接將相關函數放在倉儲中。

\\

通過將數據訪問層視作管理所有“必須發生的事情”細節的獨立庫，即可大幅減少實現過程中的錯誤數量。與此同時可以簡化基于倉儲構建的代碼，因為已經不再需要考慮“記賬”之類的任務。

\\

注意：本文會盡量提供適用于實體框架（Entity Framework）、Dapper和/或Tortuga Chain的代碼范例，然而大部分倉儲功能均可通過不依賴具體ORM的方式實現。

\\

審計列

\\

大部分應用程序最終需要追蹤誰在什么時間更改了數據庫。對于簡單的數據庫，這是通過審計列（Audit column）的形式實現的。雖然名稱可能各不相同，但審計列通常主要承擔下列四個角色：

\\

• 創建者的User Key\\t
• 創建日期/時間\\t
• 最后修改者的User Key\\t
• 最后修改日期/時間\

取決于應用程序的安全需求，可能還存在其他審計列，例如：

\\

• 刪除者的User Key\\t
• 刪除日期/時間\\t
• [創建 | 最后修改 | 刪除] 者的Application Key\\t
• [創建 | 最后修改 | 刪除] 者的IP地址\

從技術角度來看日期列很容易處理，但User Key的處理就需要費些功夫了，這里需要的是“可感知上下文的倉儲”。

\\

常規的倉儲是無法感知上下文的，這意味著除了連接數據庫時絕對必要的信息，倉儲無法獲知其他任何信息。如果能正確地設計，倉儲可以是徹底無狀態（Stateless）的，這樣即可在整個應用程序中共享一個實例。

\\

可感知上下文的倉儲略微復雜。除非了解上下文，否則無法創建這種倉儲，而上下文至少要包含當前活躍用戶的ID和Key。對于某些應用程序這就夠了，但對于其他應用程序，我們可能還需要傳遞整個用戶對象和/或代表運行中應用程序的對象。

\\

Chain

\\

Chain通過一種名為審計規則（Audit rule）的功能為此提供了內建的支持。審計規則可供我們根據列名指定要覆蓋（Override）的值。該功能包含了拆箱即用的基于日期的規則，以及從用戶對象將屬性復制到列的規則。范例：

\\\dataSource = dataSource.WithRules(\ new UserDataRule(\"CreatedByKey\

總結

以上是生活随笔為你收集整理的.NET仓储模式高级用例的全部內容，希望文章能夠幫你解決所遇到的問題。

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