Okay.
In this lesson we're just going to introduce Entity Framework and take a look at some of its features,
what it gives us and why are we going to use it in this training course and use it to help us query
our database.
And first of all, what is Entity Framework?
Well, in our application we're dealing with objects.
And we have created an entity class called product.
On the other side of things that we don't have yet, we're going to be creating a relational database.
And effectively we're going to have a products table.
Now the job of an object relational mapper, and that's what Entity Framework is, is to translate our
C-sharp code into code that SQL understands as there are two different things using two different languages.
And whilst technically it is possible to write code inside C-sharp to query our database directly and
not involve an object relational mapper, it's horrible code to write.
It's easy code to get wrong because it relies on strings and doesn't give us any type safety, and we
have to do a lot of extra work mapping between our side of things and the SQL side of things.
So the Object Relational Mapper Entity Framework, in this case there are other ORMs available, but
Entity Framework is written and maintained by Microsoft and we're building a.
Net project.
So it makes sense to use Microsoft related technologies to help us build it.
So that's the job of an object relational mapper.
So how does it work in terms of Entity Framework?
Well, Entity Framework gives us a class that we can use called a Dbcontext.
And this class provides a session with the database and manages the connection between our database
and our code on our behalf.
Inside the Dbcontext, we create DB sets which relate to tables in our actual database.
So we'll have a DB set for our products.
We'll have a DB set for our orders.
And then when we write queries against our database, we effectively write them in C-sharp and query
the DB sets.
So if we wanted a list of products we would use context, which is our DB context dot products, which
is our products table effectively.
And then to get a list of those products from the database, we just use a two list method which will
give us a list of products.
So great.
But Entity Framework and object relational mappers haven't always been around.
So let's just take a look at the good old days and see how the code used to be written without Entity
Framework.
And as we can see with this glorious code, here we have the code which we can still use today to write
a query to our database without the benefits of Entity Framework.
What we see inside here is that when we create our query, we don't get type safety.
We have to write the query in a string so we can have types in there.
Our products table might not be called products, it might be called something else.
We're not going to get any compiler help with this.
And this is about as simple a query as we can get as well.
Just selecting all from the products table.
Imagine we had a more complex query where we needed ordering and filtering and searching and other elements
that we would need to provide to this query.
And perhaps we need to join with another table as well.
That would be a very big messy query, all of which would need to be in string format and none of it
with type safety.
So a very easy way to introduce bugs into our application would be to not use something like an object
relational mapper.
Also, what we have here is the connection opened manually in our code.
Again, easy to forget and forget to close that connection to our database.
And then we can introduce further problems into our application.
Inside this particular code we've got a using keyword which we're going to talk about as we build our
application.
So not that big a deal in this case, but it is something else that we need to take care of.
And then if we take a look at what we get back from the data here, we don't get any mapping between
what we get back from SQL and what we're using inside our code.
So again, plenty of opportunity to make mistakes because of the way that we access the data that we
get back from SQL using this approach.
So that's approach.
Thankfully, we don't need to worry about nowadays because we have Entity Framework.
And if we take a look at a comparison between the two, then in this case we create an instance of our
dbcontext.
And this is a connection that's managed by Entity Framework.
And the way that we're going to use it is with dependency injection.
So the framework effectively will create a new instance of the Dbcontext on our behalf.
And then when the request is out of scope, then it's automatically going to close that connection on
our behalf.
Then it comes to the query.
We get Linq queries with Entity Framework, and the Linq query is a syntax for querying data from various
sources, not just with Entity Framework.
We can use it to query databases, XML collections, and more.
So whatever type of data it is we're querying, we can use the same syntax to do so.
In this case we're going to be querying a database.
And what we also get is automatic mapping to our C-sharp objects.
So we can access it with Productid and product name as when we get the results back from our database,
they're going to be mapped into our C-sharp objects.
So great.
But what else do we get?
Well, we get modeling.
So we can define our domain models using C-sharp classes, which we've already done with our product
class.
And then entity frameworks.
Job is to map classes and properties to database tables and columns.
We also get the ability to query our database.
And we can do so using Linq, which means we get clean, strongly typed queries without writing horrible
raw SQL code to go and get our data.
We also get change tracking, so whenever we get something from our database using Entity Framework.
Entity Framework is automatically going to track that object.
If we then make any changes to that object, entity framework is aware of it and it will detect any
updates, inserts or deletions automatically.
So when it comes to saving things into the database, then it's going to be aware of what has changed
and it will automatically generate the SQL for Crud operations to create, update and delete operations.
It also provides concurrency so it can prevent conflicts when multiple users are modifying the same
data, and it will ensure data integrity with its inbuilt concurrency control mechanisms.
And we also have transactions so we can group multiple different operations into a single atomic unit,
which means that if we've got an ad update, read deletes all within the same method, and then we come
to save those changes.
If just one of those changes fails, then everything fails and everything gets rolled back, so they
all succeed or none of them succeed.
We also get caching as well, which of course caching improves performance by caching our query results
and our entities.
So long as we're in the same session, the same open connection to our database, and we also have built
in conventions which minimizes the need for us to configure everything inside Entity Framework.
And we've already seen one convention that I mentioned with the ID.
When a class has a property with an ID property, then that's going to be the primary key for that table
for that entity.
And there are other conventions that we'll use, and I'll demonstrate as we use Entity Framework.
And they save us from writing a lot of configuration code inside Entity Framework, but we can still
configure as and when we need to.
We have many different options to do so.
And also it gives us migrations.
And this allows us to manage our database schema.
So as we write new code new entity classes we create a new migration.
And then we can get Entity Framework to write the code to update our database schema.
And this gives us incremental version controlled updates to our database as well.
So we're not going to go into SQL at any point and create a new database.
Create a new table.
Entity framework is going to manage this whole thing for us.
And we'll use migrations to do that.
So that's Entity Framework.
And coming up next we'll put it to use in our application.