I’ve never tried Dapper, but I did use Massive at my last .NET position, and it was pretty nice compared to the other ORMs I had used.
The main thing this reminded me of, though, it just how clumsy Python’s default SQL connection stuff is compared to .NET. Seriously, no transaction blocks that auto-commit or rollback? No query results objects, just keep reusing the same cursor? It seems crazy. Like 90% of Python is almost magically slick compared to .NET, but the SQL feels like such a hack.
I second Dapper. I have good experience with it, but testing it will give you a hard time when you wish to test it.
In my pet project when I got to the point that persistence is needed I thought I’ll give Dapper a second chance (later about its first chance), when I had enough of the pain of setting up migrations. Instead I went with Evolve DB migrations from Netlify, and Dapper. As I use SQLite setting up test with the in memory DB didn’t hurt that much, and I’m pretty content with Dapper at the moment.
Earlier I have already tried Dapper at work, and we faced strange issues, as we also used Dommel to automatically build (most of the) queries. As it turned out Dommel was not thread-safe in some parts and it caused strange problems in some cases. I also don’t recommend using Dommel.Extensions/Rainbow or other pseudo-ORM-s. They have the some of the features of EF, without proper docs, support, vivid community, etc. (eg. caching, lazyness, change tracking, all the stuff that can bite you if you don’t know the details well, and EF has more answers for these questions than these).
I think that If you want to use pure SQL, use Dapper. If you need an ORM, than EF is the way to go on .Net.
I’ve never tried Dapper, but I did use Massive at my last .NET position, and it was pretty nice compared to the other ORMs I had used.
The main thing this reminded me of, though, it just how clumsy Python’s default SQL connection stuff is compared to .NET. Seriously, no transaction blocks that auto-commit or rollback? No query results objects, just keep reusing the same cursor? It seems crazy. Like 90% of Python is almost magically slick compared to .NET, but the SQL feels like such a hack.
I second Dapper. I have good experience with it, but testing it will give you a hard time when you wish to test it.
In my pet project when I got to the point that persistence is needed I thought I’ll give Dapper a second chance (later about its first chance), when I had enough of the pain of setting up migrations. Instead I went with Evolve DB migrations from Netlify, and Dapper. As I use SQLite setting up test with the in memory DB didn’t hurt that much, and I’m pretty content with Dapper at the moment.
Earlier I have already tried Dapper at work, and we faced strange issues, as we also used Dommel to automatically build (most of the) queries. As it turned out Dommel was not thread-safe in some parts and it caused strange problems in some cases. I also don’t recommend using Dommel.Extensions/Rainbow or other pseudo-ORM-s. They have the some of the features of EF, without proper docs, support, vivid community, etc. (eg. caching, lazyness, change tracking, all the stuff that can bite you if you don’t know the details well, and EF has more answers for these questions than these).
I think that If you want to use pure SQL, use Dapper. If you need an ORM, than EF is the way to go on .Net.