Dapper.Rainbow VS Dapper.Contrib

dapper dapper-rainbow orm

有人可以解釋Dapper.RainbowDapper.Contrib之間的區別嗎?

我的意思是你什麼時候使用Dapper.Contrib的SqlMapperExtensions.cs,你什麼時候應該使用Dapper.Rainbow?

一般承認的答案

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

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.ContribDapper Extensions 。我不認為這是一刀切的。根據您的問題和偏好,可能會有一個最適合您的API。我試著提出一些選擇。沒有幸運的“最好的方式”來解決世界上的每一個問題。

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


熱門答案

Adam Anderson的這篇文章描述了幾個CRUD Dapper擴展庫之間的差異:

  • Dapper Contrib (自動更改跟踪 - 僅在臟或沒有時,自定義映射的屬性,無復合鍵支持,無手動鍵支持)
  • Dapper Rainbow (使用Snapshotter進行手動更改跟踪,自定義映射的屬性,無復合鍵支持,無手動鍵支持)
  • Dapper Extensions (無更改跟踪,自定義映射的Fluent配置,支持組合鍵,支持手動密鑰規範),還包括用於簡單查詢的謂詞系統
  • Dapper SimpleCRUD (無變化跟踪,自定義映射屬性,無復合鍵支持,支持手動密鑰規範),還包括過濾/分頁助手,異步支持,自動POCO類生成(通過T4)

Dapper擴展差異



許可下: CC-BY-SA with attribution
不隸屬於 Stack Overflow
這個KB合法嗎? 是的,了解原因
許可下: CC-BY-SA with attribution
不隸屬於 Stack Overflow
這個KB合法嗎? 是的,了解原因