2 ms·

My preference is currently ORM + drop back to SQL when you need something that is complicated or inefficient using the ORM. I have been writing SQL for 20 years

My preference is currently ORM + drop back to SQL when you need something that is complicated or inefficient using the ORM. I have been writing SQL for 20 years. I currently use dotNet Core and Entity Framework + Dapper. It has these benefits: - Strong types! - My schema+migrations are part of the source code and I never have to worry about if my schema is in sync - with migrations it just is - Simple, straightforward tasks as super easy (insert, update, delete, simple select) - I can fall back to Dapper (straight SQL) when I need to do something that doesnt fit well with Entity Framework. I recently worked on a project where EF was not allowed - and we spent so much time doing all the simple stuff, especially when the data model was still not completely locked down.

mrlala 6y ago
I'm a huge Dapper fan. To be fair, I have never really done a full blown project with entity framework.. but I seem to always need a bit more control than it's offering. So I just created a simple repository framework (inspired by https://www.youtube.com/watch?v=rtXpYpZdOzM https://www.youtube.com/watch?v=rtXpYpZdOzM ) overlay in which the functions end up calling dapper. The beauty of this is it's pretty simple to setup the overlay, and allows complete control of what is going on. I have a need for "dynamic" table names. I don't think there is even a way to do this in EF (at least not a simple way), but when I have my own repo overlay it's really a piece of cake. I just tack on whatever specific function input I need to help define what the resulting table name is that its great. This is probably not the most common use, but a simple repo overlay to a micro orm is not much work and gives full control.