Where's Our Data?7:14 with James Churchill
We 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
You need to sign up for Treehouse in order to download course files.Sign up