5 ms·

Any details about EFCore regrets? Too much magic, maybe?

• zvrba 8y ago
  At times too much magic, like queries mysteriously failing because you have a dangling "navigational property" without a database column. That one was a hell to debug. At other times, too little control over how the query is translated to SQL, or DB features not being exposed. With time the frustration piles up.. EDIT: I'd be OK with a light-weight ORM, like stuff these columns into these fields of that class. Leave the rest to me. Though EFCore got a bit better with support for query types so I can map classes to views / stored procedures and do the "real" work there.
• 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 ago
    For 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.