Because eventually our model update will be saved in DataStore Restore, these model classes are used
to communicate between our VPI and Restore in order to talk to the database.
We're going to use any framework in this course.
And let's start by creating a class library.
So we're adding a project and we're going to choose klus library data standard.
Again, we're going to upgrade to five later.
For now, let's use Stonner Standard to mimic the real world scenario where you have a project, most
likely you are in your workplace.
You have a lot of class libraries that is created with a framework, worked on a standard.
So we need to upgrade them later.
So let's do that.
Let's just understand a for now and then let's call it DataStore, that entity framework.
Oh, right.
So we have Wheatus first thing first we need to add a dependency package and you get package to entity
framework core.
So we're going to add the package from the from here.
And I'm going to search entity and we're going to see the first thing is the energy framework core.
And so instead of using five zero one, I'm going to use three one 10.
Just like I said, I'm going to mimic the scenario where later we have to upgrade the click.
I accept and then check the dependency packages are correctly installed.
And then now let's say let's change this to our two DB contacts and then we're going to call it bux
context.
And this context will derive from the DB context, and this comes from the entity framework for a package.
And so I did a controlled thought to import namespace.
And later now we are going to create a constructor with DB context options and these options can be
used to initialize to configure the box context and we simply just use the base class constructor to
configure the box context.
Right.
So that's the first step.
We're just passing the options to DEPI context and the options we could configure in the startup that
see us later.
But for now, let's continue with setting up the box context.
So although this course is not about entity framework wanted to cover the social part of the entity
framework in this video.
So the context really represents the database in memory because this is or M which is going to load
the data and represents the whole schema in memory.
And just and because of that, we need to kind of have a mapping between the memory and the actual tables
in the database.
Right.
So this represents the database itself.
Then we need to have the members that corresponds to the tables.
For that, we can just use simple properties and each DB set here corresponds to a table.
So we have a project.
So this is going to be corresponding to the project table.
And then next one is another DB set, which corresponds to the ticket table and I'm going to call it
tickets.
And we need to import the namespace, of course.
And of course, we need to add a reference.
This way of adding reference is very slow.
So let's go to dependancy, right.
Click on it at the product, reference to the core and then click, OK, and then I come over here and
to control that, to import the namespace.
Now I stop complaining.
And after having these properties that corresponds to the tables, we.
To configure the database schema, the relationships between the the tables, between the tables, these
two, and to do that we can override.
Remember, we are we are deriving from the context.
So there's things that we can override.
And what we are going to override is this Omoto of creating and this Omoto creating a moonshot when
this is called.
We are creating a schema within the memory that represents the database schema, the entities and the
relationships where the table was in the relationships in the data store.
We having the same relationship represented memory.
And this is the place this method is the place where we can figure that schema and all of the table
relationships here.
And what we can do is to use this model Buttar can model Buttar entity to work configuring project.
Right.
And we can say this product has many, has many because they have key.
But I need the framework uses conventions like Project ID will be much would be would be considered
as the primary key.
Same as the ticket idea here.
So you would have to call it either ID or ticket ID right in here.
You'd have to call it there.
ID or project ID then will automatically be considered as primary key and it will be identity since
you're using integer.
So there's some convention there.
Right.
So going back to the box context here, we just we don't need to say Haski, but we can say has many.
Right.
So product has many tickets.
Right.
And tickets in turn has just one product.
Right.
And also in the ticket table it has for Hinkie.
And what is the foreign key?
And that foreign key is the product I.D. and then after that, so this relationship is is created after
that.
What we can do is to seed the initial data.
So we're doing data seating, just added some test data there so that we don't end up with a with an
empty database.
So again, we can use model builder to do that.
We can say we're going to populate the product table.
Right.
And the product has initial data and the data.
You can see that it's a ray of optics, right?
Of course, it's going to be an array in this case will be an array of of product.
So a project idea is one name.
It's going to be one.
So you may be having questions regarding the project because we're specifying the ID here and you're
wondering why we're specifying because if it's identical, then it needs to be automatically generated.
But when we are ceding the data, that identity thing is turned off.
Right.
So it's going to not going to use identity when we're seeing data so we can just create a product one
and product two.
And after that, we are going to again create some ticket model builder, that entity and ticket and
then again has data and then you're having the problem.
Just delete that and then we can just have array of ticket.
And here again, we're setting the ID Tido as required.
So just say number one and then this belong to the the first product and let's have this have three.
So this is going to be built into the first project and then let's assign it to the second project and
then I'm going to have to change these numbers.
And that's it.
Right.
So now let's go to the Web API startup thus.
Yes, this is a speed UNICOR and we are going to use in-memory database if.
We are in development, right?
We're in development environment, we're going to use in-memory database, so for that, we are going
to add a dependency here.
It's going to be going to a search entity in memory to see whether we can find one.
So it's this one.
And again, I'm going to choose a lower version for now, except and it's complaining about something,
OK?
It's complaining about this.
But let's check whether sometimes it doesn't.
If there's an error, it's going to fail to install.
But in this case, it's installed already.
Right.
So we can come over here and we're going to configure the dependency injection in the configure services.
We are going to say services at a DB context, at DB context, and we're going to add the box context.
And of course, for that, we need to add a project dependency and that's going to be energy framework.
So and here we are configuring the options and the options in this case is going to be use in memory
database uppercase.
And then I'm doing controlled that import namespace.
Right.
So we call this our database box and this options here.
This configuration options is going to be passed into.
Here.
Into the constructor and then goes into the constructor of deep space class.
Right, that's when the dependency injection is triggered, when this class is required.
It needs to be created, then Delacour is going to create this.
Bux contextless passing in the options into the constructor that we specified here, and then it goes
into the constructor of the DP contacts class, but this is a memory database.
But like I said, we wanted to be used to be using in-memory database only during development.
So how do we how do we do something like this?
Environment is the ultimate inside here.
The environment comes from the variable here.
How do we how do we do that?
Well, we can use a constructor setar and then we can inject this from here.
So I'm going to try to control that and then I'm going to do this.
My studio is not configured to have the inner score for Provigil, so I'm just going to manually edit.
So Worcester's I can just call it here.
And I'm going to say if the environment is devolvement, then I'm going to use in-memory database and
then later we're going to use SQL Server.
But for now, let's just do to this here.
And but was was a memory that every time when it starts, it has to create a database in the memory.
Right.
And that has we have to have a we have to have reference to the context to the box context.
And since we have dependency injected in the configure services now, we can inject that into the configure
configure method by just doing bux context and just have the context here.
Then we can use it directly here.
And again, if the environment is development environment, then we're going to create the in-memory
database.
Right.
For that environment so we can do, as we can say, contacts database to ensure first we can do ensure,
delete it.
Probably not necessary, but just in case and to ensure, delete it.
And then we can say contacts that database ensure create it.
Right.
And that's it for now.
Later we can deal with secure server.
Right.
Let's build the solution and see whether everything builds.
Everything still builds.
So we have just added entity framework to the project, to the solution and let's sum up there certainly
a few steps that we needed to do.
First, we added the a separate class library and that's done a standard 2.0.
And the reason why I wanted to create a separate that Astorga class library to have all of to have everything
related to entity framework inside that class library is because you see the energy framework is Aurum
and it deals with all of the things that are related to connecting to database by using the framework
technology.
I don't want to mix that technology was why the API project, because it's a separate technology will
have to be decoupled.
And I don't want to mix that technology into the core library either, because you're supposed to be
playing plainer than anything else.
It's not supposed to be dependent or related or coupled with any specific technology, and that's the
reason I created a separate library for it.
And then we added a package that is and different core, and then we added the box context deriving
from the context, then we added the corresponding tables, a quote unquote, quote unquote tables.
Right.
And each dataset represents a table.
And then we overwrote the Omoto creating.
So this method creates the schema inside the memory.
And then when you run Magary, we create migration and run the migration's the schema is going to be
created inside database provided we're using a single server.
And then we you know, we add the relationship, the schema between different entities and we also seeded
the data.
Then after that we went to our Web API at the in-memory package and then we configure our DB context
in the Configure Configure Services method.
We added the box context as a dependency injection.
And and then we also configured the creation of the in-memory database right here.
There's something I wanted to add, as if we look at this method here.
There is a default, the service lifetime, the default lifetime time for the dependency injection in
this case is scoped.
Scope means that each time a HTP request it's sent to our Speedman A in this case is by the API application.
A new instance of BUX contacts will be created, but the instance will be the same instance for the
entire request and response cycle.
So the first request comes in and then so let's see whether we have that picture still here.
So we have a service listening to the port.
So the request comes in and then the remotely hosted Metters process the request.
Right.
And does the data manipulation and then response would come back?
I didn't draw that, but the response would come back.
So this request request and the response cycle is as one cycle.
So this for this entire one cycle, there's going to be only one bux context, right?
That's what it means by scope, by scoped life time scoped lifetime.
I just want to clarify that.