The ORM is definitely very read-focused, which is probably not that surprising given that it's used for web, and given the motivations for creating it, discussed at the blog post mentioned by @gokhan [1].
It would be nice to have some lightweight stuff for updating/inserting too, though I guess doing it in such a way that you don't need to write lots of boilerplate kinda requires SQL generation, which dapper is avoiding on purpose.
Interesting use of code generation - pretty cool, oft unused part of .net/C#. Also interesting how it's designed to be a drop-in single C# file, that often seems the easier way of getting functionality into a project, side-stepping DLL version issues.
Looking at the dynamic code gen... is it necessary? Can't they just use a method that takes 'type' and the set of properties as arguments? I'm sure I'm missing something, but don't see it at the moment.
I find it interesting that they support text SQL queries, as that was a feature I explicitly left out. My library is about minimizing the amount of repetition in code while supporting calls to stored procedures.
My biggest problem with Dapper was the lack of MySQL support, so I updated it to work with all databases by going the ADO.NET only route. You can find my work here:
If you hang out on github, and do your social coding over there (or simply prefer git over Mercurial), here is a github fork of the repository: https://github.com/dbarros/dapper-dot-net
Gap of about 20ms between compiled Linq2SQL and this looks enticing. I guess this can be used at hot spots with optimized SQL queries using existing LINQ2SQL entities.
Definitely not for everyone. The whole reason it exists perhaps is to kill SQL translation time and avoid dealing with data readers.
Kudos for making it OSS.
Also, Entity Framework takes about 800ms unoptimized. That is almost a second to execute a query. I can't begin to imagine what the performance of its solution would be in the hands of a new developer.
Edit: I misread about the EF performance. Sorry about that.
I notice this is using data readers. I'm not an expert but I believe they keep the connection (and therefore any database locks) until you've finished processing and closed the reader. Given that it's for hydrating strongly typed collections into memory you aren't going to be ignoring any records. You might get even better throughput at the database (at the expense of memory usage in the app) by using datasets which will run the query, then close the connection, then return all the results to the app.
I strongly disagree. If you use a DataAdapter to populate a dataset, all it's doing is iterating over a reader internally and loading the results into the dataset. There's no reason it would ever be as fast, let alone faster, than using a reader yourself to populate a data structure that you actually want.
Locks really shouldn't be happening with a datareader on a modern database with MVCC isolation (SQL2005+ and Oracle, etc.) unless you have specifically lowered isolation.
http://samsaffron.com/archive/2011/03/30/How+I+learned+to+st...
Another framework in the same direction is Rob Connery's Massive:
http://blog.wekeroad.com/helpy-stuff/and-i-shall-call-it-mas...