Plans for Entity Framework Core 6.0 revealed as Microsoft admits it is unlikely to match Dapper for performance Microsoft's next major version of its Entity Framework (EF) database library for .NET will have long-term support and attempt to match rival Dapper for performance – an attempt, said senior program manager Jeremy Likness, that "will likely not be fully achieved." Entity Framework is Microsoft's Object-Relational Mapping (ORM) …
So it's not even finished and they're already saying it's not going to be as good as their main rival?
Sounds to me like a coded way of saying "yeah, well, management thinks it's still worth bothering with, but if we're being honest everyone that works on it really wishes you'd all stop using it."
To be honest my comment was really around the apathy of the development team. It just felt like a coded "why are we even bothering" to be honest.
There's a lot of criticisms of the way EF works, many of which are valid. If it's the tool you need, it's the tool you need. I've looked at both that and Dapper and neither of them have met the needs of the projects I've been working on, although that might say more about the nature of the projects I work on than the platforms themselves.
Dapper and Entity Framework aren't competitors, they're very different, Dapper is more of an easier replacement for ADO.Net code, it just handles your object mapping. Entity Framework can build your tables for you, write your queries and basically replace SQL entirely.
Very different toolsets, I often use both in the same applications for different purposes.
And if you use a database that allows you to define a "virtual" table based on an underlying SQL query, you can tweak the JOIN or the data model subsequently without having to tweak the application.
There is clearly some mechanistic tedium involved in constructing a runtime object from a database row, but that was a largely-solved problem when COBOL was invented. I'm not convinced the convolutions of EF to deal with foreign keys add anything, and as soon as you start having to think how the supposed abstraction is actually working behind the scenes, the abstraction loses it value.
Not to mention that a lot of work goes into database query optimisation - you don't want an ORM second-guessing it.
Nice to see PostgreSQL called out - it's actually a very good platform for creating application-specific views of the database in a way that decouples the data from the application much more effectively than ORMs - at least in my opinion. And frankly, if you're trying to manipulate a database efficiently without knowing SQL, you need someone who does know SQL (or at least how the queries are executed) to do the work behind the scenes for you.
It's horses for courses, of course.
One of the reasons I like Entity Framework and Visual Studio is that it can be used to automate the creation of the C# accessor classes from whatever tables are in a given database. That makes it pretty easy to evolve a db schema during development missing out that mechanistic tedium.
Getting rid of that tedium is, I find, quite liberating; one can make a lot of changes, additions, etc. pretty rapidly with a minimal risk of misunderstanding between the application and database as to what the tables look like. I don't think it can be done as part of the build process - I've never looked - but I've been quite happy in the past just pressing the few necessary buttons.
I'm aware that, to a proper db-aware developer, I must sound like a right numpty; they'd be spot on. But it does make it possible for those of us who aren't so hot with db's to make effective use of them without spending too much time on the matter. And I guess that, afterall, that was MS's intent. The end result clearly isn't and, judging by the tone of the ambition reported in this article, may never be as optimum as hand crafted SQL, but then again making that switch from EF to pure SQL would for many be something they're prepared to put off until v2.0 of a system.
Indeed. Use of EF is a time saver that avoids a lot of the humdrum of talking to a back end. Left to its own devices, EF can create some pretty cranky queries, but fairly simple logging/analysis of the generated SQL gives a good indication of where things need to be looked at in more detail. There are also plenty of simple optimisation tweaks you can/should make in high level code before it gets parsed by EF. Another benefit is that you can run the same high level data access code against different versions of SQL Server, and it will take advantage of that server version's capabilities.
Sure, you can make things more efficient if you hand-code stored procedures and invoke them directly. If you've got the time to do that. Or you have a dedicated db team. You could even dispense with a high level language and write your next utility app in assembly language. But we don't do that because life is short, delivery times are short.
Nah, don't bother with stored procedures, your app logic should stay in the client where it belongs.
However using something like dapper to avoid the mapping tedium and plain SQL does feel like it makes things simpler?
I suppose it depends how much time you spend analysing queries and optimising higher level code vs how much time you save not writing SQL.
I have found personally, centralising the repository and therefore decoupling the objects from the storage. does mean that you don't have to worry when someone uses them in a way that makes an ORM blush. Also, because you have a nice well defined boundry to the data storage you can expose an interface that is designed to be as performant as possible, which will also have the effect of making it's consumers at least consider this insofar as they're constrained by it.
Not always possible to have all the logic in the code. Sometimes a good SP can handle the complex joins needed in a complicated query way better than any coder can do at the code level.
We have some very complex queries that could be done in the client but the performance compared to an optimized SP just plain sucked.
One place where SP's suck in their own right is versioning, or a lack thereof. Would be a nice feature to have.
This post has been deleted by its author
Anything that makes it easier for a developer to spin code is guilt free until you get the call at 4 in the morning after the dev has departed to wreak havoc anew elsewhere and the edge case reveals the ghastly mess in the trace logs, acres of machine generated bollocks SQL.....
As a DBA, I loathe Entity Framework (and ORMs in general)
I see it as time stolen from the DBAs so that the developers can meet their deadlines.
EF is performance optimisation hell. SQL Server keeps nice data about what objects are run, how often, what execution plans they use and so on.
If stored procedures have become resource hogs or taking their sweet bloody time to execute, SQL Server provides the data for me to react.
But with EF I get these long ugly chunks of SQL that I have to dissect. And even then, it can't be guaranteed that the next execution of the same EF code will result in the same SQL. So when someone from Helpdesk or a PM says that the x functionality is running slow, I can look at the SQL and hold my head and sigh.
Running baselines for objects is doable with SPs but not really with EF.
It all has to go back to the developers, which means that the problem won't be solved until another couple of sprints.
At least with SPs I can test the code in the object, optimise in and submit it in a sprint myself
But the ADO.NET benchmark doesn't take into account the conversion from the SQL driver output (for lack of a better word) to the C# class or record. That conversion IS included in the Dapper benchmark time (the same holds for the EF benchmark time).
So the difference is probably a lot less than implied.
I've been using Entity Framework for a years. Generated query is a way complex than the one written by "hands".
If you need X records from DB data you have to ask DB to give you those X records, nothing more, not X+2, nor X+3, or so. Mapping to any sort of list is very quickly, not worth to mention.
There is an overhead as Entity Framework has to convert LINQ into T-SQL, obviously.
To be frank I don't understand what's the really concern here? Slow query or EF itself on generating corresponding T-SQL?
Besides this, we have threshold, so API has to respond under 400ms. Usually that means not only grid page (30 records, usually), but also getting some extra data from DB triggering more than one query to the SQL Server DB. Some really critical and slow queries are inside stored procedure as you can do there a lot of magic (locks, forcing indexes, temp tables.
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
