Preview
Video Player
00:00
00:00
Where's Our Data?
7:14We know that our application is persisting data, but how is this working? And where is our database?
When we updated the console lab to use
our context we saw that a comic book with
0:00
the series title The Amazing Spider-Man
was added every time that we ran our app.
0:05
So, we know that our application is
persisting data but, how is this working?
0:11
And where is our database?
0:16
We can see the database
that EF is creating for
0:18
us by using Visual Studios Sequel Server
optic explorer.
0:21
Press control Q to place the focus
in the quick launch search box.
0:25
Type sql server and
select the first item in the list.
0:30
Under the SQL server node,
0:35
we can see a list of the SQL server
instances that we're connected to.
0:37
If you don't see the MS SQL
local DB instance,
0:41
click the add SQL server
icon to connect to a server.
0:45
Click on local, then MS SQL local DB.
0:49
The authentication field should
be set to Windows authentication
0:53
meaning to use our current
Windows account name.
0:58
Username and
1:01
password should be disabled as they're
not used with Windows authentication.
1:01
And the database field can be left blank.
1:07
Click Connect to connect to the server.
1:10
Once the server appears in the list you
can double-click the server name and
1:13
then the database's folder to see a list
of the servers available databases.
1:17
The ComicBookGalleryModel.Context database
is the database that EF created for
1:22
our application.
1:27
EF name the database by combining
our Visual Studio project name with
1:29
our context class name,
separated by a dot.
1:33
Double click the database and
1:37
then the tables folder to see
a list of the databases tables.
1:38
Our database currently has two tables.
1:43
dbo.__MigrationHistory and dbo.ComicBooks.
1:47
The dbo prefix that appears
before the table names
1:54
is the name of our database
is default schema.
1:58
A schema is a distinct namespace
similar to C# name spaces
2:00
to facilitate the separation and
management of database objects.
2:05
For our purposes in this course,
we'll stick with using the dbo Schema.
2:10
For more information about database
Schemas, see the teachers notes.
2:14
If we double click
the comicbook table name,
2:18
Visual Studio will open
a design view of the table.
2:20
In the top half of the tab is a list of
the table column names and data types.
2:23
Along with whether or not,
the column allows no values.
2:29
The in four card data type is
a variable length Unicode string,
2:33
the max part within the parentheses,
indicates that the column can contain
2:37
a string as large as the maximum allowed
size, which is a very large strain,
2:42
two gigabytes or
approximately a billion characters.
2:47
We'll see in the next section how we
can refine our data model and restrict
2:52
the allowable number of characters to
a more specific reasonable number.
2:56
In the bottom half of the tab is the sql
statement that would create our table.
3:00
We can also expand the arrow
to the left of the table name
3:06
in the sql server object explorer window,
and
3:09
double click the columns folder to
see a list of the table columns.
3:13
This gives us three different ways
to review the design of our table.
3:16
For now,
let's ignore the migration history table,
3:21
we'll come back to it at
the end of the section.
3:24
Okay, we know where our databases and
what it generally looks like,
3:27
but how did it get created?
3:32
How do we get from our
model to a database?
3:34
The first time that we access the context's comic books db set property,
3:38
EF will check of the database exists and
if it doesn't exist, it will create it.
3:43
When creating the database, EF will use
our model to determine what tables and
3:49
table columns to generate.
3:54
Remember that EDMX file that we
briefly reviewed in the first section?
3:57
When using the code first workflow,
4:01
EF generates an in memory version of
the EDMX file using type discovery.
4:04
Type discovery is the process that EF
uses to discover all of the entities that
4:09
are part of our model.
4:14
[SOUND] EF starts with compiling
a list of the entities that have DbSet
4:16
properties defined in our context.
4:20
From there, it'll walk the available entity relationships to discover any
4:23
entities that aren't represented by dbset properties.
4:28
Our model currently doesn't have any entity relationships.
4:32
We'll see examples of relationships
in the next section for each entity.
4:36
EF also compiles a list of the properties,
and for
4:41
each property various characteristics, such as its data type and nullability.
4:45
All of this information about our
entities makes up what is called
4:51
in EDMX terms the conceptual model.
4:55
EF then uses a set of conventions to
generate the database representation
4:58
of the conceptual model.
5:03
That's called the storage model.
5:05
And then, map the conceptual
model to the storage model.
5:08
The default convention is for
5:12
the entity to be represented
by a table in the database.
5:14
The name of the table is
either the singular or
5:18
plural version of the entity class name.
5:21
Depending upon whether or
5:23
not EF has been configured to use
the pluralizing table name convention.
5:25
If EF finds a property on the entity whose name matches the convention of ID,
5:30
ID, class name ID or
class name ID then EF will add a primary
5:36
key column to the table with
the same name and data type.
5:41
If the property's data type is numeric or
a globally unique identifier or
5:45
GUID, then EF will also make
the column an identity column.
5:51
For more information about GUIDs,
see the teacher's notes.
5:55
As mentioned in an earlier video,
5:59
identity columns are automatically
assigned values by the database.
6:01
When new records are added to the table.
6:06
EF also adds an entity property that has a setter, public protected or
6:09
private as a table column.
6:13
Mapping the Property's Name
to the Column Name and
6:15
the property's .NET Data Type to the
appropriate SQL Server Column Data Type.
6:18
The column's nullability
is determined by evaluating
6:23
if the .NET data type is nullable or not.
6:27
So, a column mapped from a property with
a data type of int wouldn't allow nulls.
6:30
Whereas a column mapped from a property
with a data type of string would.
6:36
The conventions that EF uses, including
all of the conventions that we've
6:41
discussed, can be customized to
fit your particular requirements.
6:45
So far,
most of these conventions make sense for
6:49
our application, though we've already seen
how the text-base columns in the comick
6:52
book table could be refined to use
a more specific allowable string length.
6:58
We'll see examples of how to customize or
7:03
override the default conventions
in the next section.
7:05
But first, let's see in the next video how
we can change the name of our database.
7:09