2 ms·
Compared to writing Sql stored procs it feels really hard to write something that spits out efficient sql. You can't run (as far as I'm aware) things like quer
by LandR 8y ago
Compared to writing Sql stored procs it feels really hard to write something that spits out efficient sql.
You can't run (as far as I'm aware) things like query analyzers like I can with SQL to get execution plans.
It can be an absolute nightmare to debug. Like proper hell that where you can lose a day or so over something that ends up being stupidly simple.
I hate it and would choose just doing SQL with a plain ORM anyday over ever touching EF again.
When I was using it it also had poor support for immutable types. I imagine this has got better.
- prakhunov 8y agoFor any slow performing query you can always log the raw sql that is generated and run a normal explain like always. You should also have database profiling tools in your disposal at all times, regardless if you use an ORM or just raw SQL. ORMs are great when used sparingly and properly. For a bunch of normal crud operations they are great because they get rid of a lot of boilerplate code. Also as with any ORM you can always drop down to raw sql in the situations that require it.