有人可以解釋Dapper.Rainbow與Dapper.Contrib之間的區別嗎?
我的意思是你什麼時候使用Dapper.Contrib的SqlMapperExtensions.cs,你什麼時候應該使用Dapper.Rainbow?
我現在已經使用Dapper一段時間了,並且想知道Contrib和Rainbow項目對我自己的影響。經過一些代碼審查,以下是我對其用途的看法:
Contrib在IDbConnection接口上提供了一組擴展方法,用於基本的CRUD操作:
Contrib的關鍵組成部分是它為您的實體提供跟踪,以確定是否已進行更改。
例如,使用帶有接口的Get方法作為類型約束將返回動態生成的代理類,其中包含內部字典以跟踪已更改的屬性。
然後,您可以使用Update方法,該方法將生成僅更新已更改的屬性所需的SQL。
Major Caveat :要獲得Contrib的跟踪優點,必須使用Interface作為類型約束來允許生成代理類。
Rainbow是一個Abstract類,您可以將其用作Dapper類的基類,以提供基本的CRUD操作:
以及一些常用的方法,如First(獲取表中的第一條記錄)和All(獲取表中的所有結果記錄)。
出於所有意圖和目的,Rainbow基本上是最常用的數據庫交互的包裝器,並將基於屬性名稱和類型約束構建無聊的SQL。
例如,使用Get操作,Rainbow將構建一個vanilla SQL查詢並返回所有列,然後將這些值映射回用作約束的類型。
類似地,插入/更新方法將基於類型約束的屬性名稱動態地構建插入/更新所需的SQL。
Major Caveat :Rainbow希望你的所有表都有一個名為“Id”的標識列。
Contrib和Rainbow之間的主要區別在於(IMO),其中一個跟踪您實體的變化,另一個不跟踪:
旁注:我希望我早些時候看過Rainbow,因為我已經建立了一個與Dapper一起使用的非常相似的基類。
從文章和引用@anthonyv引用: 那令人討厭的INSERT問題,將數據導入數據庫
現在還有2個其他API可以選擇( 除了Rainbow )(對於CRUD) Dapper.Contrib和Dapper Extensions 。我不認為這是一刀切的。根據您的問題和偏好,可能會有一個最適合您的API。我試著提出一些選擇。沒有幸運的“最好的方式”來解決世界上的每一個問題。
我懷疑Sam在上面的引文中試圖傳達的內容和相關的博客帖子是:您的場景可能需要大量自定義映射(使用vanilla Dapper),或者它可能需要跟踪實體更改(使用Contrib),或者您可能有常見的使用場景(使用Rainbow)或者你可能想要使用它們的組合。或者甚至不使用Dapper。因人而異。
Adam Anderson的這篇文章描述了幾個CRUD Dapper擴展庫之間的差異: