Monthly Archives: November 2013

Code-First Migrations

Continuing my series on Code first development and workflow, in this blog post I’m covering Code First Migrations. Code First Migration facilitates database changes, implemented and completely driven by changes to the properties of the POCO classes, which define the domain specific object model. Code First Migrations fully support the convention over configuration, and agile application development processes. When practicing a code first development strategy, you immediately dive into an iterative and evolutionary approach to development. With the agile approach, the form and functions of the domain model are continuously evolving over the entire course of the software development life-cycle. You need a simple, fast and smooth mechanism, that will automatically apply object model changes to the database, over many iterations of development.

Visual Studio 2013 automatically generates a Migrations folder in the project, to store a time stamped history of all code first migrations generated for the project. Here is an illustration of the Migrations folder in my current project.

Code First Migrations Folder in the Solution Explorer

Code First Migrations Folder in the Solution Explorer

Here is an example of the code generated in a Code First Migration class.

You can customize the code generated by the migrations engine.

To learn more about Code First Migrations see this walkthrough.

Independent and Dependent Foreign Key Properties

As the form and functions of my domain model evolved, I decided that the performance of the navigation properties of the models could be improved by adding the foreign key property directly into the model, and annotating the navigation properties with the foreign key attribute. This not only improved data access performance, it also streamlined much of the user interface development, when I generated controllers and views directly from the models in the MVC 4 and MVC 5 templates.

Here is a link to stackoverflow that has a very good discussion on Independent Associations Versus Foreign Key Associations

Code-First and ASP.NET MVC 4

With this post I’m continuing my series of articles on Code-First development and workflow. In previous articles I developed a complete domain model for a project management application. This model includes POCO classes, that define each of the entities in the project management domain, along with a database context model defined in Entity Framework. Now I’m ready to build a web application based on this domain model, utilizing the Model View Controller (MVC) design pattern.

At first I decided to build the website using the ASP.NET Web Forms Application template in Visual studio 2012. I figured, since I already developed the domain model, and had Entity Framework generating the object model, I could simply hand craft the controller and view components and add them to the website in separate folders or class libraries. After all, the domain model consists of only nine entities;

  • Customer
  • Industry
  • Person
  • Project
  • Rate
  • Task
  • Timesheet
  • Timesheet Entry
  • Title

However, it didn’t take long to realize, that developing and unit testing all of the classes and methods, required to support the controllers and views for each entity, would be an overwhelming task for one person. Consider this, each entity requires one controller class. Each controller class requires eight action methods to support the Create, Read, Update, Delete (CRUD) operations, which are necessary to maintain each entity of the domain. Each CRUD operation must be supported by a separate view in the user interface. Here is the minimal inventory of components required to support the MVC design pattern with a model consisting of 9 entities;

  • 9 Controller Classes
  • 72 Action Methods
  • 45 View Classes
  • 126 Total components

The minimal number of components required to support an MVC design pattern over a domain model with 9 entities is 126. I estimate this amounts to over 3,000 lines of code. This is an overwhelming coding task for one person. However, MVC is a standardized, repeatable pattern. I decided to take some time to look into automating this development effort.


I changed my strategy, and restarted development of the project management website, using the ASP.NET MVC 4 Web Application template in Visual Studio 2012. I’m not going to get into all of the details of how to build the website using the MVC 4 website template. Instead, I will describe how I incorporated the project management domain model, which I had previously developed, into the MVC 4 website template. However, if you are new to ASP.NET MVC 4, here is an excellent step-by-step tutorial on building an ASP.NET MVC 4 web application called Intro to ASP.NET MVC 4.

Integration Of The Project Management Domain Model Into ASP.NET MVC 4

The ASP.NET MVC 4 Web Application template, generates a fully functional web application based on the MVC design pattern. The website project generated by the template provides a folder called Models. I simply added a C# file to the Models folder and named it ProjectManagementModels.cs. I also declared a name space of Lexicon.ActionManager.Models in the C# file. Then I copied all the source code, of the project management domain model POCO classes, into this one C# file. The result is illustrated below. Notice how the solution explorer in Visual Studio 2012 makes navigation of this rather large source code file very easy.

Project Management Models in Visual Studio 2012

Figure 1. Project Management Models in Visual Studio 2012

I also copied the database context class into this same C# file, as illustrated here.

Database context class to generate object model with Entity Framework

Figure 2. Database context class to generate object model with Entity Framework

Here is the entire source code file ProjectManagementModels.cs.

Adding Controllers And Views For The Project Management Domain Model Into ASP.NET MVC 4

Integrating the project management domain model into ASP.NET MVC 4 was easy enough. Adding the necessary controller and view components was even easier. To add a controller class, simply right-click on the Controllers folder in the Solution Explorer of Visual Studio. This will present a context menu. Hover the mouse pointer over the add menu option to display the sub-context menu, and then click on the controller option. This will display the Add Controller dialogue box, as illustrated in Figure 3.

In the Add Controller dialogue box, first give the new controller class a name. To follow the configuration over convention style of developing, which is supported in ASP.NET MVC 4, the controller name should be the same as the model entity it controls, with a suffix of Controller. In this case, I’m generating a controller class for the project domain entity of the model. Therefore, I simply named the new controller class “ProjectController”.

The Add Controller dialogue box offers numerous Scaffolding options – see Figure 3. This gives the developer total control over the amount of automation and scaffolding generated by ASP.NET MVC 4. The Scaffolding Options are presented in three drop down list boxes;

  • Template – a list of scaffolding template options
  • Model Class – a list of all the entity classes defined in the model
  • Data Context Class – a list of all classes in the model, including the Entity Framework database context class, which defines the object model
  • For Template, I want the highest level of automation and generated scaffolding in my project, so I selected the “MVC controller with read/write actions and views, using Entity Framework”.
  • For Model Class, I selected the “Project” class option from the model
  • For Data Context Class, I selected the “ProjectManagementContext” class option from the model

Finally, after selecting the three scaffolding options, simply click the add button and the ProjectController class is automatically generated, with the eight action methods implementing the CRUD operations to maintain Project objects. The ProjectController class is automatically added to the Controllers folder. The five view classes, which provide the user interface support for the CRUD operations, are also automatically generated and added to the Views folder in the solution explorer. Everything was automatically generated according to specifications I selected in the Add Controller dialogue box.

The results of the generated scaffolding are impressive. The ProjectController class has eight action methods and 128 lines of code. Five views were automatically generated with 553 lines of code. All of this code is fully functional right out of the box.

Adding the project controller to the ASP.NET MVC 4 project

Figure 3. Adding the project controller to the ASP.NET MVC 4 project

Here is the generated code of the ProjectController class;


The development approach I outline in this article probably isn’t for everyone. Some may argue that a certain level of control and flexibility, in structuring an application, is sacrificed with this approach. However, small shops and one person operations, can definitely benefit from the efficiency gained by the automatically generated application scaffolding. There is also a significant improvement in quality, and testing efficiency, gained from tapping into the know how, and capabilities, of a much large community of developers, who are continuously making contributions to the ASP.NET MVC model.