So as promised,
we're going to kick things off in this module by exploring what Entity Framework
Core is really all about and what it can mean for your application. If you have
worked with earlier versions of Entity Framework, so perhaps BRE.NET Core even,
you'll see what has changed here too.
I think it's a given that nearly every application that we build will
need data. In a previous module, the list page we created used data,
but it was hardcoded. Having data inside the code is not what we want
in a real‑life application.
The data should probably be in a database. To access data in a database, well,
we have a couple of options.
The most low‑level approach to access data is using ADO.NET. Using
ADO.NET, we can bring in raw SQL statements or invoke a stored
procedure, and then we can, for example,
read data using a data reader. While that still works, it is often
a lot of extra work and it requires that the developer will know a
lot about writing SQL statements.
Instead what we will do is use Entity Framework Core, or EF Core for short.
You have probably heard of Entity Framework already before,
perhaps in the context of a ASPNET MVC where it was also used. Entity
Framework Core is really the next version of Entity Framework,
the ORM, or object relational mapper, from Microsoft. An ORM will allow us to
work with the data in a database without having to write directly any SQL
statements, in most cases that is, and basically allows us to work with types
that will, behind the scenes, be persisted to the database. Just like previous
versions of Entity Framework, EF Core allows us to work with LINQ statements to
interact with the data.
EF Core is a very lightweight framework and can be a good companion
in combination with ASP.NET Core applications. Just like .NET Core
and ASP.NET Core, EF Core is also working in a cross‑platform way,
so it will still allow you to interact with the database on Linux or
other platforms.
Also again,
just like .NET Core itself, EF Core is also open source.
You can find the source code on GitHub.
EF Core supports working with SQL Server and is basically
the default for ASP.NET Core applications.
But we're definitely not limited to using only SQL Server. EF
Core allows us to work with other databases, even
non‑relational data stores are supported.
While that is not the focus of this course, it's interesting
to keep this in mind if the requirements of a project force
you to use another database.
One last thing that's also important to keep in mind compared to
previous versions of Entity Framework is that EF Core only
supports a code‑first based approach. A database‑first approach
isn't supported any longer.
That means that EDMX files, for example, can't be used anymore.
However,
you can still start to an existing database with EF Core and
have it scaffold what you need in code.
If you're still a bit unclear on the role and goal of an ORM like EF Core,
let me explain it in a bit more detail.
As I explained just a few slides ago, to work with data in the database, we
can write SQL statements in our code or calls to procedures in code. While
that approach has worked for many years and actually still works, an ORM
getting the life of a developer much easier. Developers typically like to work
with classes and objects and that's where EF Core comes in. The ORM sits
between our code and database.
We will do changes with objects which will result in changes in the database.
This enables us, as developers, to focus on the code part and not so much
on the database side of things. Here's a small example.
In our application,
we have a type called Pie along with some properties. Through EF Core,
the type will be mapped to a table in the database where the
properties of our class appear as columns on the table.
EF Core will typically take care of creating this table for you if needed.
Based on the type of the properties of the Pie class, it will figure out
what types it needs to give to the created class.
EF Core uses quite a few conventions as well.
For example, on the Pie class,
the property with the name ID or PieId will, by default,
become the primary key in the database.
In our code,
we can now perform operations using Pie instances and EF Core will update
the corresponding table in the database accordingly.
An ORM like EF Core also works with a change tracker built
in, and we'll see that in action later.
This means that when we load one or more entities from the database,
they are kept, lets say, in‑memory. We can then encode and make changes to the
properties, and when we ask EF Core to update the record,
all records,
it will automatically look at which properties have changed and
update the data in the database accordingly.
And this is very handy, you'll see. There are many advantages to using EF Core
compared to going more low level with, for example ADO.NET.
Once you get the hang of it,
you'll see that writing data access code becomes well,
a lot simpler.
Since you're doing everything directly in code, for most
operations you'll want to do with the database,
you won't need to write SQL statements or store procedures anymore. EF
Core will write the SQL for you behind the scenes.
However,
you may run into situations where an ORM doesn't do exactly
what you want it to do, and in that case,
you can still use a raw SQL statement in combination
with EF Core. In terms of performance,
there might also be cases where EF Core is somewhat slower compared
to a regular SQL statement, but as mentioned,
you can combine both approaches with ease.