As .NET Core matures into a production-ready software product, more and more information is becoming available regarding what to expect. While the changes haven't been too big to understand, there are breaking changes and they do require that developers get some education before forging ahead.
A Short History Of The (EF) World
Entity Framework started with version 3.5, which is a neat trick if you think about it. The first two versions, 3.5 and 4, were built into the .NET Framework --- meaning you had to wait until a new Framework release if you wanted any improvements or (shudder) bug fixes. It was the very model of a monolithic framework --- did Gilbert & Sullivan write that? Any tooling for EF was built into Visual Studio.
Versions 4.x through 5 were a bit of an improvement; the core functions were still baked into the .NET Framework, but new components were available on NuGet. Again, the tooling was available in Visual Studio.
Version 6.x saw EF completely removed from the .NET Framework --- can you see an evolution here? --- and were made available from NuGet, with any tooling available from the download center. Finally, things were separated and available more quickly.
With EF Core, things are not just separate, they're even more specific. You don't even get relational database support "out of the box" any more.
(Seriously; when did you last get software in a box?)
What does this mean? You write code to get what you want --- I've heard it referred to as "pay to play" --- and you get speed. I've seen decent real-world demos that were 80 percent faster. As Colin Chapman said, "Add lightness". MOAR SPEED!
Less memory and less CPU usage, too. That's great for mobile applications, sure, but it's also great for cloud-based applications where you pay for CPU cycles.
As you might expect, with a version 1.0 of anything, some things aren't quite ready. Doing without lazy loading, stored procedure mapping, and a robust LINQ translator are prices to be paid for being on the cutting edge. Basic LINQ expressions work fine, but those full-page LINQ queries won't fly just yet.
You can see a roadmap for EF Core on the EF Core wiki page.
"Yeah, yeah, let's see some code."
Example Code: Using a SQL Server Database
Notice in note 1, you now specifically call out your database provider. In this case, SQL Server with a connection string. This could just as easily have been <code>.UseSqlite(dbconn) to use a SQLite database, as noted in the comments. Again, bits are added only as you need them, saving memory and CPU cycles and improving performance.
Another performance improvement involves improved SQL statement generation by EF Core. In EF 6.x, if you were writing several records to a database, EF would create an INSERT statement for each record. With EF Core, that's been reduced to one (albeit lengthy) SQL statement. One round trip now, versus N trips before. You can even, if you wish, set the "batch size" for batched commands.
(Side note: I wanted to capture the generated SQL for a large insert in EF Core, but the
Context.Database.Log function is not available in EF Core --- just more evidence of the newness of a version 1.)
There are other, more in-depth improvements and changes in EF Core; I've provided enough here to get you started. I suggest following along at the github repo to keep up-to-date.
Finally, you can run this on Windows, sure, but you can really push the envelope if you want to: Grab a zero-dollar, developer's copy of Red Hat Enterprise Linux to run in a Virtual Machine and start writing #dotNETonLinux.
All The Best,
For additional information and articles on .NET Core visit our .NET Core web page for more on this topic.
Last updated: March 15, 2023