Dapper.Rainbow VS Dapper.Contrib

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)

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.

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.