ORM: Should I go Micro?

We had an interesting internal discussion about ORMs (Linq to SQL, Entity Framework, …) and MicroORMs (Dapper, Massive, PetaPoco, …). This discussion led me to think about: When should I use a MicroORM?

I would go for the approach: Use both (MicroORM and BigORM) and use them where they make sense.

 

A possible decision approach:

1. Start with Entity Framework (Big ORM)
2. Measure performance (as you should do anyway, see my posts http://blog.gfader.com/2011/07/website-check-list-part-1-aspnet-4.html )
3. Find bottlenecks
4. Entity Framework is your bottleneck? --> replace with a MicroORM
   I can almost guarantee you that EF is *not* your bottleneck

This is how Sam Saffron came to the conclusion to write Dapper in the first place, as per his blog post: http://samsaffron.com/archive/2011/03/30/How+I+learned+to+stop+worrying+and+write+my+own+ORM

Things to consider before going Micro:

Going to these MicroORM's we lose a lot of features that many of us loved to have, e.g.

1. Compile time evaluation of queries
   
     var post = connection.ExecuteQuery<Post>("select * from Posts where Id = @Id", new {Id = 1}).First();
   
2. Intellisense that comes with LINQ
   
3. "Unit of Work" pattern (Tracking of entities) - Relevant for state full applications (WPF and Windows Forms)
   
4. No "Map of Identities" - Knowing about object identities
   Ensures that each object gets loaded only once by keeping every loaded object in a map. Looks up objects using the map when referring to them

 

If you don't care about the above features and you want easy deployment (1 file drop) and best performance out of database-access go Micro!