Dapper.NET - "micro-ORM" that poweres StackOverflow goes opensource

Related blog post:

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...

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.

[1]: http://samsaffron.com/archive/2011/03/30/How+I+learned+to+st...

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.

I did something somewhat similar to this and have been iterating it for several years http://sqlsiphon.codeplex.com/

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:

https://github.com/managedfusion/dapper-dot-net

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.

We have an open source ORM here: http://www.agilefx.org. Sits on top of Linq-To-Sql and adds features found in Entity Framework.

Looking for contributors.

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.

Please fix typo in title (poweres).