Code-First Development Workflow

By Tim Daniels
Over the past few weeks I’ve continued using the code-first workflow. At this point, I’m ready to share what I’ve learned and what I’ve developed so far. The code-first workflow enabled me to use the convention over configuration approach in the design and development of a solution. With this approach, I found myself focusing, almost exclusively, on the application of a solution to a business problem. Some thought and effort was given to architecture and application structure, but I did’nt concern myself with database design, or object model design, other than verifying that what was generated by the Entity Framework matched my requirements and expectations. The result was a solution, and code, that is very simple and concise. A complete, normalized relational database, and a complete object model were automatically generated by the Entity Framework.

Here is a brief description of the solution I’ve been developing. I call the application “Action Manager”. It’s a basic project management application written in C#.NET. The application will record and track the number of hours worked on a specific task, by a specific person, on a specific project, for a specific customer. The data is stored in a SQL Server database. For development purposes, I’m using SQL Server 2012, the express edition. The entire application is build on the .NET Framework 4.0.

In designing and developing an application, I first get a thorough understanding of the business domain the application will operate in. Understanding a business domain requires identification, and definition of the entities existing in the domain, and how they interact with each other. These entities are then abstracted into individual object-oriented classes in code. Here is a list of the entities currently identified and defined in the project management domain;

  • Customers
  • Projects
  • People (who work on the projects)
  • Titles (job titles)
  • Tasks
  • Rates
  • Timesheets
  • Timesheet entries

Following are the C# classes representing each of the entities in the project management domain. These classes are completely independent of a database source, the object relationship model (ORM), and any third-party attributes. They are also independent of any base class inheritance. This type of class is sometimes refered to as a plain old common language runtime object, or POCO class. I created one class library project called “Entities” to store these classes.

Convention over configuration
Examine each entity class closely. You will notice that the entities have properties which define relationships with other entities in the domain. For example, The customer class has a property called projects. This property is defined as a generic list of project objects. This establishes the conventional relationship between customers and projects, that is customers can have one to many projects. In the same way, the person class has a property called time sheets, establishing the convention that a person can submit one to many time sheets for work performed on a project. These properties are called navigation properties in the object model.

Notice also, that each class has an ID property defined with an object type of integer. The property is named after the class with a suffix of Id (e.g., CustomerId and PersonId). This naming convention is used by the entity framework to create a unique key column when generating tables in a database. This also facilitates the creation of primary key and foreign key relationships, in the object model and the database.

Entity Framework
The Entity Framework can use the conventional relationships established in these POCO classes to automatically generate an object model, and a relational database schema. The DbContext class is where this can be accomplished. The DbContext class is in the System.Data.Entity namespace. Let’s look at some code to see how this is done.

In the above code snippet I created a class called ProjectManagementContext which is derived from DbContext. I then added a property for each of the classes in my entity class library. The type of each property is DbSet. When developing with the Code First workflow you can define a derived DbContext that represents your session with the database and exposes a DbSet for each type in your model. The DbSet Class represents a typed entity set that is used to perform create, read, update and delete operations for each of the entities defined in the object model of the context.

Here is an illustration of the object model generated by the Entity Framework, based on the conventions defined in the POCO classes of the Entity class library. Notice the Navigation Properties, and how they form relationships between the objects in the model. For example, the one to many relationship between the customer object and the project object, is clearly illustrated here.

Object model generated by the Entity Framework in Code-First Workflow

Object model generated by the Entity Framework in Code-First Workflow


Here is an illustration of the database and database model generated by the Entity Framework.
Database generated by the Entity Framework in Code-First Workflow

Database generated by the Entity Framework in Code-First Workflow

In the near future I’ll be writing about the Entity Framework’s fluent API. I’ll also explore the implementation of the create, read, update and delete methods in the DbSet of entity class.

Here are several helpful links to help you get familiar with Entity Framework Development Workflows and the code-first workflow.

2 thoughts on “Code-First Development Workflow

  1. Pingback: Code-First Entity Framework’s Fluent API | The Lexicon of Software

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">