[1/4] Become a Full Stack .NET Developer: Building a Model Using Code-first Workflow

After the pre-planning and visual mockup phase was over, we could now start the initial coding of our app's first iteration. For this project we will be using a code-first approach as popularized in recent versions of Entity Framework, that allows us to write the classes for our domain model first and automatically create a database from these, rather than creating a database first and fitting our classes to it.

Using Entity Framework rather than say ADO.NET, also comes with the convenience of not having to write low level SQL statements in our code.

So after firing up Visual Studio for the first time in our project, we first need to enable code-first migrations to the database. This was done in the Package Manager Console by typing "enable-migrations". So during coding our project anytime we changed the domain model in someway, we would need to go to the Package Manager Console and Type "add-migration <MigrationName>". Entity Framework will then update the schema of the database to correspond to our changes, so we never have to go to SQL Server and manually modify database tables.

View fullsize

Reviewing migration changes before commiting them to the database.

After running a migration but before committing it to the database we can review the changes by going to the Migrations folder in the Solution Explorer and looking at the class that was created for our migration (which is named by a timestamp followed by the migration name we gave it). In here we can actually see the SQL code that has been automatically generated. Assuming we are happy with this, we can now commit the migration to the database by going back to the Package Manager Console and typing "update-database".

After learning the fundamentals of code-first, we proceeded to write our main domain classes in the Models folder. In the Gigs class our attributes were Artist (derived from ASP.NET's User Identity class),  DateTime and Venue. Genre was given its own separate class.

We then needed to add a DBSet for the Gigs and Genre classes to IdentityModels.CS so that Entity framework will know about these two classes for code-first migrations.

View fullsize

The sturutre of our datbase after our first migration. We then proceeded to use Data Annotations to make sure that the Venue, Artist_Id and Genre_Id were not allowed to be nullable.

After running a migration and creating the structure of our new database, we then viewed the database in the Server Explorer.

One problem with our new database was that the Venue, Artist_Id and Genre_Id were set to allow null values, were for our app's purposes that should not be the case. This allows null default was in place because of Entity Framework's Convention Over Configuration settings. To override these conventions we briefly discussed two methods: Data Annotations (easier to implement, but has limitations) or Fluent API (more flexible, but harder to implement). We decided to use Data Annotations for now, and possibly refactor Fluent API into a subsequent iteration of our app later on. So to achieve this, in the Gig and Genre classes we applied the Data Annotation [Required] above the Artist, Venue and Genre properties.

Following on from this we had to make a quick design decision on how we were going to populate the Genre table of the database. We could either make a admin page, were an end user could add musical genres for the different types of gigs, or we could run a simple SQL script in our migration class before committing it to the database to populate it with the genres that way.

It was decided that a new admin page for something that hardly ever changes (there are only a limited number of musical genres such as Rock, Pop etc...) was outside the scope of what was asked for in the requirements document, while also adding alot more overhead to the project. So in the end we went for a script to add the genres to the database.

Afterwards we made a new database migration (with our manual script changes) and then committed our code to the Visual Studio Online repository.