WEBVTT

00:00.020 --> 00:00.200
Okay.

00:00.230 --> 00:04.460
In this lesson we're just going to introduce Entity Framework and take a look at some of its features,

00:04.460 --> 00:11.420
what it gives us and why are we going to use it in this training course and use it to help us query

00:11.420 --> 00:12.590
our database.

00:12.590 --> 00:16.070
And first of all, what is Entity Framework?

00:16.070 --> 00:18.800
Well, in our application we're dealing with objects.

00:18.800 --> 00:22.730
And we have created an entity class called product.

00:22.760 --> 00:28.130
On the other side of things that we don't have yet, we're going to be creating a relational database.

00:28.130 --> 00:31.220
And effectively we're going to have a products table.

00:31.220 --> 00:38.840
Now the job of an object relational mapper, and that's what Entity Framework is, is to translate our

00:38.840 --> 00:46.820
C-sharp code into code that SQL understands as there are two different things using two different languages.

00:46.820 --> 00:54.380
And whilst technically it is possible to write code inside C-sharp to query our database directly and

00:54.380 --> 00:59.270
not involve an object relational mapper, it's horrible code to write.

00:59.660 --> 01:04.910
It's easy code to get wrong because it relies on strings and doesn't give us any type safety, and we

01:04.910 --> 01:10.380
have to do a lot of extra work mapping between our side of things and the SQL side of things.

01:10.380 --> 01:16.320
So the Object Relational Mapper Entity Framework, in this case there are other ORMs available, but

01:16.320 --> 01:21.300
Entity Framework is written and maintained by Microsoft and we're building a.

01:21.450 --> 01:22.080
Net project.

01:22.080 --> 01:27.420
So it makes sense to use Microsoft related technologies to help us build it.

01:28.440 --> 01:30.930
So that's the job of an object relational mapper.

01:30.930 --> 01:34.680
So how does it work in terms of Entity Framework?

01:34.710 --> 01:39.240
Well, Entity Framework gives us a class that we can use called a Dbcontext.

01:39.240 --> 01:45.690
And this class provides a session with the database and manages the connection between our database

01:45.690 --> 01:48.180
and our code on our behalf.

01:48.210 --> 01:55.080
Inside the Dbcontext, we create DB sets which relate to tables in our actual database.

01:55.080 --> 01:56.880
So we'll have a DB set for our products.

01:56.880 --> 01:58.920
We'll have a DB set for our orders.

01:58.920 --> 02:05.400
And then when we write queries against our database, we effectively write them in C-sharp and query

02:05.400 --> 02:06.750
the DB sets.

02:07.020 --> 02:13.710
So if we wanted a list of products we would use context, which is our DB context dot products, which

02:13.710 --> 02:16.200
is our products table effectively.

02:16.200 --> 02:21.780
And then to get a list of those products from the database, we just use a two list method which will

02:21.780 --> 02:23.010
give us a list of products.

02:23.010 --> 02:24.210
So great.

02:24.210 --> 02:28.110
But Entity Framework and object relational mappers haven't always been around.

02:28.110 --> 02:34.560
So let's just take a look at the good old days and see how the code used to be written without Entity

02:34.590 --> 02:35.370
Framework.

02:35.370 --> 02:42.180
And as we can see with this glorious code, here we have the code which we can still use today to write

02:42.210 --> 02:46.590
a query to our database without the benefits of Entity Framework.

02:46.620 --> 02:50.940
What we see inside here is that when we create our query, we don't get type safety.

02:50.970 --> 02:55.680
We have to write the query in a string so we can have types in there.

02:55.710 --> 02:59.160
Our products table might not be called products, it might be called something else.

02:59.160 --> 03:01.590
We're not going to get any compiler help with this.

03:02.580 --> 03:05.730
And this is about as simple a query as we can get as well.

03:05.730 --> 03:08.400
Just selecting all from the products table.

03:08.550 --> 03:14.430
Imagine we had a more complex query where we needed ordering and filtering and searching and other elements

03:14.430 --> 03:17.560
that we would need to provide to this query.

03:17.560 --> 03:19.990
And perhaps we need to join with another table as well.

03:19.990 --> 03:25.660
That would be a very big messy query, all of which would need to be in string format and none of it

03:25.690 --> 03:26.920
with type safety.

03:26.920 --> 03:32.860
So a very easy way to introduce bugs into our application would be to not use something like an object

03:32.860 --> 03:34.090
relational mapper.

03:34.120 --> 03:39.340
Also, what we have here is the connection opened manually in our code.

03:39.700 --> 03:44.380
Again, easy to forget and forget to close that connection to our database.

03:44.380 --> 03:48.040
And then we can introduce further problems into our application.

03:48.070 --> 03:52.810
Inside this particular code we've got a using keyword which we're going to talk about as we build our

03:52.810 --> 03:53.500
application.

03:53.500 --> 03:58.540
So not that big a deal in this case, but it is something else that we need to take care of.

03:58.540 --> 04:04.870
And then if we take a look at what we get back from the data here, we don't get any mapping between

04:04.870 --> 04:09.340
what we get back from SQL and what we're using inside our code.

04:09.340 --> 04:15.250
So again, plenty of opportunity to make mistakes because of the way that we access the data that we

04:15.250 --> 04:18.100
get back from SQL using this approach.

04:18.190 --> 04:20.450
So that's approach.

04:20.480 --> 04:24.440
Thankfully, we don't need to worry about nowadays because we have Entity Framework.

04:24.470 --> 04:31.460
And if we take a look at a comparison between the two, then in this case we create an instance of our

04:31.460 --> 04:32.750
dbcontext.

04:32.750 --> 04:35.660
And this is a connection that's managed by Entity Framework.

04:35.690 --> 04:39.410
And the way that we're going to use it is with dependency injection.

04:39.410 --> 04:44.450
So the framework effectively will create a new instance of the Dbcontext on our behalf.

04:44.450 --> 04:50.990
And then when the request is out of scope, then it's automatically going to close that connection on

04:50.990 --> 04:52.220
our behalf.

04:52.250 --> 04:53.630
Then it comes to the query.

04:53.660 --> 05:01.430
We get Linq queries with Entity Framework, and the Linq query is a syntax for querying data from various

05:01.430 --> 05:03.440
sources, not just with Entity Framework.

05:03.440 --> 05:08.960
We can use it to query databases, XML collections, and more.

05:08.990 --> 05:14.330
So whatever type of data it is we're querying, we can use the same syntax to do so.

05:14.330 --> 05:16.820
In this case we're going to be querying a database.

05:16.820 --> 05:20.990
And what we also get is automatic mapping to our C-sharp objects.

05:20.990 --> 05:27.540
So we can access it with Productid and product name as when we get the results back from our database,

05:27.540 --> 05:30.630
they're going to be mapped into our C-sharp objects.

05:30.630 --> 05:31.770
So great.

05:31.770 --> 05:33.540
But what else do we get?

05:33.570 --> 05:35.580
Well, we get modeling.

05:36.150 --> 05:40.800
So we can define our domain models using C-sharp classes, which we've already done with our product

05:40.800 --> 05:41.790
class.

05:41.970 --> 05:43.470
And then entity frameworks.

05:43.470 --> 05:48.030
Job is to map classes and properties to database tables and columns.

05:49.080 --> 05:52.260
We also get the ability to query our database.

05:52.260 --> 05:59.730
And we can do so using Linq, which means we get clean, strongly typed queries without writing horrible

05:59.730 --> 06:03.450
raw SQL code to go and get our data.

06:03.600 --> 06:09.690
We also get change tracking, so whenever we get something from our database using Entity Framework.

06:09.720 --> 06:13.200
Entity Framework is automatically going to track that object.

06:13.200 --> 06:18.870
If we then make any changes to that object, entity framework is aware of it and it will detect any

06:18.870 --> 06:22.080
updates, inserts or deletions automatically.

06:22.080 --> 06:27.960
So when it comes to saving things into the database, then it's going to be aware of what has changed

06:27.960 --> 06:35.550
and it will automatically generate the SQL for Crud operations to create, update and delete operations.

06:35.580 --> 06:40.410
It also provides concurrency so it can prevent conflicts when multiple users are modifying the same

06:40.410 --> 06:46.950
data, and it will ensure data integrity with its inbuilt concurrency control mechanisms.

06:46.980 --> 06:54.180
And we also have transactions so we can group multiple different operations into a single atomic unit,

06:54.180 --> 07:01.500
which means that if we've got an ad update, read deletes all within the same method, and then we come

07:01.500 --> 07:02.700
to save those changes.

07:02.700 --> 07:08.460
If just one of those changes fails, then everything fails and everything gets rolled back, so they

07:08.460 --> 07:11.280
all succeed or none of them succeed.

07:11.370 --> 07:17.700
We also get caching as well, which of course caching improves performance by caching our query results

07:17.700 --> 07:19.050
and our entities.

07:19.050 --> 07:25.350
So long as we're in the same session, the same open connection to our database, and we also have built

07:25.350 --> 07:31.050
in conventions which minimizes the need for us to configure everything inside Entity Framework.

07:31.050 --> 07:35.390
And we've already seen one convention that I mentioned with the ID.

07:35.420 --> 07:43.520
When a class has a property with an ID property, then that's going to be the primary key for that table

07:43.520 --> 07:44.750
for that entity.

07:44.930 --> 07:50.300
And there are other conventions that we'll use, and I'll demonstrate as we use Entity Framework.

07:50.300 --> 07:56.270
And they save us from writing a lot of configuration code inside Entity Framework, but we can still

07:56.270 --> 07:58.400
configure as and when we need to.

07:58.430 --> 08:00.650
We have many different options to do so.

08:00.650 --> 08:03.710
And also it gives us migrations.

08:03.710 --> 08:06.770
And this allows us to manage our database schema.

08:06.770 --> 08:12.410
So as we write new code new entity classes we create a new migration.

08:12.410 --> 08:17.210
And then we can get Entity Framework to write the code to update our database schema.

08:17.210 --> 08:22.340
And this gives us incremental version controlled updates to our database as well.

08:22.340 --> 08:26.240
So we're not going to go into SQL at any point and create a new database.

08:26.240 --> 08:27.770
Create a new table.

08:27.800 --> 08:31.040
Entity framework is going to manage this whole thing for us.

08:31.040 --> 08:33.230
And we'll use migrations to do that.

08:33.230 --> 08:34.850
So that's Entity Framework.

08:34.850 --> 08:38.690
And coming up next we'll put it to use in our application.