Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / entity-framework / EF6.0

Entity Framework Code First Entities and entity relationships

3.43/5 (4 votes)
23 Sep 2015CPOL5 min read 6.5K  
This article is a part of a multi-post article on Entity Framework Code First for web applications: Entity Framework Code First Entities and entity relationships Entity Framework Data Context Entity Framework Migrations and Data seeding It is not very often that I see web development tutorials

This article is a part of a multi-post article on Entity Framework Code First for web applications:

  1. Entity Framework Code First Entities and entity relationships
  2. Entity Framework Data Context
  3. Entity Framework Migrations and Data seeding

It is not very often that I see web development tutorials focusing on db level with entities and their relationships. But, whatever web application you start working on, chances are you will need a database to store and read some information. In this post, I will try to give a short description of entities and how relations are created between them in the context of Entity Framework Code First, as the data access layer of a web application. Let’s see first what is Entity framework.

About Entity Framework Code First

Entity framework is Microsoft’s Object Relational Mapping (ORM) solution. It supports the communication between the code and the database, facilitating the development of the database structure (by generating DML code automatically), data access, and mapping the data between data sets and objects of our code. Entity framework enables us to develop the data access layer in three ways: database first, model first, and code first. The development of these methods have come in a progressive way, code first being the latest approach, and personally I would say, it is the most flexible one. It allows us to develop our database starting from the code. This gives us the possibility to think from the code’s perspective and enable us to structure our code as it fits best the application logic, not the database organization.

What is an Entity class?

Basically, entities are simple classes which represent entities of the application. Usually, every entity corresponds to a database table and in a way becomes the code representation of that table. An example might be, if we have the table persons in the database, we might have the class Person which represents a single record of that table. As the class represents a single person, it’s name is singular, and table’s name is usually in plural. Entity Framework by default take care about pluralization of table names by convention.

Creating an Entity class

Creating an Entity class is as simple as defining a class. Usually, classes have some properties inside them. Let’s model our entity class Person and see how it might look.

public class Person
{
   public int Id {get; set;}
   public string Name {get; set;}
   public string Surname {get; set;}
   public DateTime BirthDate {get; set;}
}

If we examine this class, we see that it has four properties, one integer number named Id, two string properties Name and Surname, and one DateTime property BirthDate, all representing personal details of a Person. Based on this definition of the Person class, Entity Framework creates persons table by examining these properties. We’ll go little deeper in the db creation in the next post.

Decorating Entities with validation attributes

Leaving Entities plain as in the example above will keep the code clean and readable. This kind of Entity is called a Plain Old CLR Entity or POCO for short. In some scenarios, it might be a good strategy to stick to POCO style and keep the Entities clean and put the validation code in some other partial classes or other parts of the code.

Entity framework gives us the possibility to decorate the classes and class properties with attributes, which are later used during the process of creating the database tables, and the client side validation in ASP.NET MVC. These decorations serve in two perspective: 1) they enable the Entity Framework to understand the property and gather metadata based on which will create the table columns; 2) they enable the client side validation of the input data for those properties to be done automatically.

Let us decorate the Person class with some attributes.

public class Person
{
   public int Id {get; set;}

   [required]
   public string Name {get; set;}

   [required]
   [MaxLength(50)]
   public string Surname {get; set;}

   public DateTime BirthDate {get; set;}
}

I have decorated Name and Surname properties. Now, both have the validation attribute [required]. Validation attributes are written inside brackets. The required attribute marks a property as required and this will translate as not null in the database. From this, we can see that we have made Name and Surname properties. The surname attribute is also decorated with a second validation attribute, which is MaxLength. MaxLength tells the maximum length (when the data type is string, this is the length of characters, when the data type is number, it is the length of numbers) of a column in a database. For more details about validation attributes please refer to this link on MSDN.

Defining relationships between Entities

The benefit of Code First approach of Entity Framework is that it allows you to define the whole database structure from within the code, this includes the relations between the entities as well. Let’s suppose that we have a lookup table countries which holds the list of countries. Now, we need to assign every Person entity a country. How can we do that?

We start by defining our Country entity first:

public class Country
{
  public int Id {get; set;}
  public string Name {get; set;}
}

Now that we have our country entity, we can add the relation to the Person entity by modifying the class

public class Person
{
   public int Id {get; set;}

   [required]
   public string Name {get; set;}

   [required]
   [MaxLength(50)]
   public string Surname {get; set;}

   public DateTime BirthDate {get; set;}

   public virtual Country Country {get; set;}
}

By adding a reference to a Country entity we are telling the Entity Framework that we want to a relation between Person and Country entities. We have also quantified it as one to many, as one Person can have one country, but one country can be assigned to multiple persons, this definition will result to one to many relationship between Person and Country entities. The relationship diagram will look like this:

Image 1

You may refer to this link for further details on defining relationships.

Conclusion

Entity Framework Code First approach will give you a good possibility to focus on code and and define everything from there. It gives you the flexibility to in a declarative form to define all the properties of database structure and change it accordingly as the code evolves. In the next posts, we will go through the defining the Data Context which is the backbone of the data access layer and after that we will focus on how to create the database from the code, feed it with data, and manage the changes in the database structure.

The post Entity Framework Code First Entities and entity relationships appeared first on arian-celina.com.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)