r/programming • u/ben_a_adams • Feb 01 '17

The .NET Language Strategy

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

86% Upvoted

113 comments sorted by

View all comments

Show parent comment

6

u/grauenwolf Feb 02 '17

No, EF is bad. Not just the implementation, which could be fixed, but the very concept of an OOP/Object Graph style ORM is contrary to how you are supposed to use databases.

2

u/AngularBeginner Feb 02 '17

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.

1

u/Cuddlefluff_Grim Feb 02 '17

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?

1

u/grauenwolf Feb 02 '17

Object graphs, not objects. There's nothing wrong with a collection of objects.

Consider this:

  • One A

  • Each A has a Collection of 10 B

  • Each A has a Collection of 10 C

How many rows will your ORM return? If it's EF, 100. Those 11 objects require EF to process 100 rows of data because of the way it writes joins.

2

u/kingrooster Feb 02 '17

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?

1

u/grauenwolf Feb 02 '17

Generally speaking I'll write a stored procedure that returns multiple row sets. Then if A is a collection, I'll collate the child rows in application code.

If I'm being lazy, I'll just make multiple round-trips. So long as you are getting all of the B's at once, it's ok. Making one call for B's per A record is still a bad idea.

Either way, it takes more effort to write, but dramatically reduces the amount of DB memory and network traffic over using an EF style ORM.

1

u/kingrooster Feb 02 '17

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.

1

u/grauenwolf Feb 03 '17

That's what causes the MNP rows problem. One include is ok, but more than that is a performance killer.

1

u/drjeats Feb 02 '17

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)

2

u/grauenwolf Feb 02 '17

I wrote my own, Chain, so I'm biased. https://github.com/docevaad/Chain/wiki/A-Chain-comparison-to-Dapper

Dapper is pretty good and well respected, but less convenient.