3 ms·
>As soon as you want to do something that's not already perfectly built in, everything becomes a mess of impenetrable hacks. Use the ORM for perfectly built in
by vsareto 6y ago
>As soon as you want to do something that's not already perfectly built in, everything becomes a mess of impenetrable hacks.
Use the ORM for perfectly built in things, but also use raw SQL when it's not.
- GordonS 6y agoThis is a pattern I've used before with dotnet, and I think it works quite well. Generally we start with Entity Framework Core, because it's well known and let's us compose and execute queries really easily (I should add we always use a "code first" approach; the actual database is created carefully by us, not the ORM). For some apps, you need to do more complex stuff, such as use composite keys, duplicating rows, etc - while this might technically be possible with EF Core, it's horrible in practice. Also in some cases you just can't coax EF to generate a performant query. In these cases we either add a view, or we add a micro-ORM into the mix, like Dapper - you basically write the SQL yourself, but Dapper helps marshal data from the database to your classes.