我現在已經使用Dapper一段時間了，並且想知道Contrib和Rainbow項目對我自己的影響。經過一些代碼審查，以下是我對其用途的看法：

Dapper.Contrib

Contrib在IDbConnection接口上提供了一組擴展方法，用於基本的CRUD操作：

• 得到
• 插
• 更新
• 刪除

Contrib的關鍵組成部分是它為您的實體提供跟踪，以確定是否已進行更改。

例如，使用帶有接口的Get方法作為類型約束將返回動態生成的代理類，其中包含內部字典以跟踪已更改的屬性。

然後，您可以使用Update方法，該方法將生成僅更新已更改的屬性所需的SQL。

Major Caveat ：要獲得Contrib的跟踪優點，必須使用Interface作為類型約束來允許生成代理類。

Dapper.Rainbow

Rainbow是一個Abstract類，您可以將其用作Dapper類的基類，以提供基本的CRUD操作：

• 得到
• 插
• 更新
• 刪除

以及一些常用的方法，如First（獲取表中的第一條記錄）和All（獲取表中的所有結果記錄）。

出於所有意圖和目的，Rainbow基本上是最常用的數據庫交互的包裝器，並將基於屬性名稱和類型約束構建無聊的SQL。

例如，使用Get操作，Rainbow將構建一個vanilla SQL查詢並返回所有列，然後將這些值映射回用作約束的類型。

類似地，插入/更新方法將基於類型約束的屬性名稱動態地構建插入/更新所需的SQL。

Major Caveat ：Rainbow希望你的所有表都有一個名為“Id”的標識列。

區別在哪裡？

Contrib和Rainbow之間的主要區別在於（IMO），其中一個跟踪您實體的變化，另一個不跟踪：

• 如果希望能夠跟踪實體中的更改，請使用Contrib。
• 當您想要使用更符合標準ADO.NET方法的內容時，請使用Rainbow。

旁注：我希望我早些時候看過Rainbow，因為我已經建立了一個與Dapper一起使用的非常相似的基類。

從文章和引用@anthonyv引用： 那令人討厭的INSERT問題，將數據導入數據庫

現在還有2個其他API可以選擇（ 除了Rainbow ）（對於CRUD） Dapper.Contrib和Dapper Extensions 。我不認為這是一刀切的。根據您的問題和偏好，可能會有一個最適合您的API。我試著提出一些選擇。沒有幸運的“最好的方式”來解決世界上的每一個問題。

我懷疑Sam在上面的引文中試圖傳達的內容和相關的博客帖子是：您的場景可能需要大量自定義映射（使用vanilla Dapper），或者它可能需要跟踪實體更改（使用Contrib），或者您可能有常見的使用場景（使用Rainbow）或者你可能想要使用它們的組合。或者甚至不使用Dapper。因人而異。