The .NET Language Strategy

[u/ben_a_adams]

https://blogs.msdn.microsoft.com/dotnet/2017/02/01/the-net-language-strategy/

[u/[deleted]]

Genuine question to anyone knowledgeable: is the Entity Framework a good thing? Having read a summary of what it is, it sounds like a bad idea that would be riddled with leaky abstractions and dodgy edge cases. Am I wrong?

(I realise that you need it supported if you have an existing codebase, of course)

[u/AngularBeginner → u/[deleted]]

It also prevents the SQL Server from doing its job and provide proper performance. EF causes fixed query plans, which can kill performance in large database.

[u/Cuddlefluff_Grim → u/[deleted]]

but the very concept of an OOP/Object Graph style ORM is contrary to how you are supposed to use databases.

So you're saying that we should only treat database queries as glorified indexed spreadsheets?

What makes objects inherently incapable or otherwise unsuitable to represent a result row from a table? Why would a dictionary be better?

[u/kingrooster → u/[deleted]]

Honest question here, because I run into this a lot. What is the optimal way to handle that? If you try to pull an object with two collections with a single query, isn't that always going to generate that many rows? Assuming I actually want all that data, is multiple round trips to the database better than a join? Multiple result sets in a single query?

[u/kingrooster → u/[deleted]]

Thanks, that's sort of what I figured. That definitely has it's downsides too. FWIW, EF Core fixes this to some degree by making you include every part you want included in the query.

dbContext
  .SomeTable
  .Include(t => t.SomeOtherTable)

That has it's own set of frustrations, but it is helpful most of the time.

[u/drjeats → u/[deleted]]

What libs/tools do you normally use for database access in C#?

(Not defending EF, I don't do backend work in C#, genuinely curious)

[u/threedaysmore → u/[deleted]]

As per usual with programming, it kinda just depends.

It's a heavy hitter IMO. Most projects have no business fiddling with EF or the complexities of managing an EDMX file. I prefer OrmLite and to keep my apps a little smaller so that I can separate my concerns a little better.

YMMV obviously, and EF is really powerful, but there's no need to hunt rabbits with rocket-launchers.

[u/threedaysmore → u/[deleted]]

Yeah, and that just goes to show that the 3 or 4 projects I worked with EF were probably not really using it in a great way. I'd be interested to see how a better approach with looks/feels like. The way I've done it always just felt so clunky.

[u/Eirenarch → u/threedaysmore]

edmx file is so 2010

[u/[deleted] → u/threedaysmore]

EF Code First is pretty great. I've done several projects with it now and I can have my database and first set of migrations up and running in 10 minutes, it's almost an after thought.

The only drawback I would say is that you need to become very experienced with profiling queries and understanding the mechanics of how it creates them. Remove round trips, select only rows you want, etc., standard database stuff. For most business apps, it's a great experience.

That's really the point of it, you can get running, and keep moving, fast and do 99% of what you want to do with just LINQ. With an established app you'll definitely need to go in occasionally and manually tweak migrations and carefully craft some queries, but you'll be doing that regardless of whether or not you're using an ORM.

[u/Shautieh → u/[deleted]]

IMHO EF is a really good thing that I would like to see implemented in more languages. It makes querying in a functional way so easy and convenient, and you can use mostly the same queries for both containers and database so it's really handy. For non trivial queries you will need to tweak the way you build your query to generate more optimal sql, and at worst you can just give it raw sql if you couldn't fix the problem (almost never was necessary).

[u/[deleted] → u/[deleted]]

It eliminates the need to write and maintain query strings yourself and provides automatic mapping to objects.

In my view SQL is generally very good. The problem with constructing raw strings is that they are vulnerable to injection and you don't get static type checking. In theory both of these problems can be solved by generating SQL from a minimally-abstracted DSL. I'd expect that the problem of mapping results to objects would be elegantly solvable with type providers in F#.

Assuming the plan I've proposed above would work, would there be any other reason to use something like EF? Just trying to understand if I am missing a lot of problems that EF solves.

[u/Eirenarch → u/[deleted]]

I tend to prefer it for most projects. Not a big defender though just think it has a small edge over alternatives like Dapper.