Dapper.Rainbow VS Dapper.Contrib

Question

Can someone please explain the difference between Dapper.Rainbow vs. Dapper.Contrib?

I mean when do you use SqlMapperExtensions.cs of Dapper.Contrib and when should you use Dapper.Rainbow?

Beason

Answer 1

I’ve been using Dapper for a while now and have wondered what the Contrib and Rainbow projects were all about myself. After a bit of code review, here are my thoughts on their uses:

Dapper.Contrib

Contrib provides a set of extension methods on the IDbConnection interface for basic CRUD operations:

• Get
• Insert
• Update
• Delete

The key component of Contrib is that it provides tracking for your entities to identify if changes have been made.

For example, using the Get method with an interface as the type constraint will return a dynamically generated proxy class with an internal dictionary to track what properties have changed.

You can then use the Update method which will generate the SQL needed to only update those properties that have changed.

Major Caveat: to get the tracking goodness of Contrib, you must use an Interface as your type constraint to allow the proxy class to be generated.

Dapper.Rainbow

Rainbow is an Abstract class that you can use as a base class for your Dapper classes to provide basic CRUD operations:

• Get
• Insert
• Update
• Delete

As well as some commonly used methods such as First (gets the first record in a table) and All (gets all results records in a table).

For all intents and purposes, Rainbow is basically a wrapper for your most commonly used database interactions and will build up the boring SQL based on property names and type constraints.

For example, with a Get operation, Rainbow will build up a vanilla SQL query and return all columns and then map those values back to the type used as the constraint.

Similarly, the insert/update methods will dynamically build up the SQL needed for an insert/update based on the type constraint's property names.

Major Caveat: Rainbow expects all your tables to have an identity column named “Id”.

Differences?

The major difference between Contrib and Rainbow is (IMO), one tracks changes to your entities, the other doesn’t:

• Use Contrib when you want to be able to track changes in your entities.
• Use Rainbow when you want to use something more along the lines of a standard ADO.NET approach.

On a side note: I wish I had looked into Rainbow earlier as I have built up a very similar base class that I use with Dapper.

---

From the article and quote @anthonyv quoted: That annoying INSERT problem, getting data into the DB

There are now 2 other APIs you can choose from as well (besides Rainbow) (for CRUD) Dapper.Contrib and Dapper Extensions. I do not think that one-size-fits-all. Depending on your problem and preferences there may be an API that works best for you. I tried to present some of the options. There is no blessed “best way” to solve every problem in the world.

I suspect what Sam was trying to convey in the above quote and the related blog post was: Your scenario may require a lot of custom mapping (use vanilla Dapper), or it may need to track entity changes (use Contrib), or you may have common usage scenarios (use Rainbow) or you may want to use a combination of them all. Or not even use Dapper. YMMV.

Restraint

Excellent answer. Rainbow has 40k downloads and Contrib over 2 million. Seems like everyone is using Contrib, maybe even for the Rainbow style functionality as I guess Rainbow is a subset of Contrib? – Nuthouse

Answer 2

This post by Adam Anderson describes the differences between several CRUD Dapper extension libraries:

• Dapper Contrib (Automatic change tracking - only if dirty or not, Attributes for custom mapping, No composite key support, No manual key support)
• Dapper Rainbow (Manual change tracking using Snapshotter, Attributes for custom mapping, No composite key support, No manual key support)
• Dapper Extensions (No change tracking, Fluent config for custom mapping, Supports composite keys, Supports manual key specification), also includes a predicate system for simple queries (NOTE: deprecated - does not support recent Dapper versions nor .NET core)
• Dapper SimpleCRUD (No change tracking, Attributes for custom mapping, No composite key support, Supports manual key specification), also includes filtering/paging helpers, async support, automatic POCO class generation (through T4)

Blomquist

Hi! Is there a way to get the tracked data using Dapper.Contrib? For example, I want to check "old" and "new" values in changed fields before performing an update to database. Thanks! – Foraminifer

From what I see in the source as of 11/2017, Dapper Contrib only has a IProxy.IsDirty flag which is set if any of the properties of the "tracked" object are modified. So the only thing that Update does is that it checks whether IsDirty is true, and then updates all columns. Dapper.Rainbow "Snapshotter" is probably the tool you are looking for. – Blomquist

I have already tried Snapshotter, but I want something already done in Dapper. With Snapshotter I have to create the logic to compare changed fields, etc. Thanks. Please, check this if you want, I created this thread: github.com/StackExchange/Dapper/issues/876 – Foraminifer

Not sure of your semantic on "manual key," but Dapper.Contrib supports both non-auto-generated keys (e.g. identity, auto_increment) and keys with names other than "Id" via KeyAttribute and ExplicitKeyAttribute. – Harker

working link to original article by Adam Anderson: web.archive.org/web/20160807040540/http://blog.falafel.com/… – Braley

DapperExtensions is an abandoned project. Be cautious when using it! It does not support the latest Dapper version and cannot be used in .NET core projects. – Generalization

@metabuddy: updated the answer, thanks. I guess this is why questions like this are off topic on SO. :) – Blomquist

Answer 3

Sam describes in details what the difference is in his post - http://samsaffron.com/archive/2012/01/16/that-annoying-insert-problem-getting-data-into-the-db-using-dapper.

Basically, its the usual not 1 size fits all answer and its up to us to decide which approach to go with based on your needs:

There are now 2 other APIs you can choose from as well (besides Rainbow) (for CRUD) Dapper.Contrib and Dapper Extensions. I do not think that one-size-fits-all. Depending on your problem and preferences there may be an API that works best for you. I tried to present some of the options. There is no blessed “best way” to solve every problem in the world.

Raised

I don't see where Sam describes the difference in his post. He describes Dapper.Rainbow then mentions that there is also Dapper.Contrib. But what is the actual difference between the two implementations? – Trescott