Conventions in Entity Framework Core

Conventions are the default rules that control how a model will be mapped to a database schema. Entity Framework core follows these default rules when it is not overridden using Data Annotation Attributes and Fluent API.

Tables

EF Core creates database tables for all the DbSet<TEntity> properties included in the DbContext class. It will also create tables for entities that are not added to the DbContext class if that entity is referenced in other DbSet<TEntity> entities present in the DbContext to form a relationship (primary key/foreign key). In such a scenario, the referenced entity's class name will be used as the table name.   

In the following example, the Student Entity and the Attendance entity are connected. But, only the Student entity has the DbSet property in the  AppDbContext class. But EF Core will create a table for Attendance entity also as it is in a relationship that is defined fully at both ends. 

//AppDbContext which inherits DbContext class
    public class AppDbContext : DbContext
    {
        public AppDbContext(DbContextOptions<AppDbContext> options) : base(options)
        {          
        }
        
        public DbSet<Student> Students { get; set; }
    }

//Student Entity
  public class Student
    {
     
        public int StudentId { get; set; }
        public string Name { get; set; }
        public ICollection<Attendance> Attendance { get; set; }
    }

//Attendance Entity
 public class Attendance
    {
        public int Id { get; set; }
        public bool Attended { get; set; }
        public DateTime Date { get; set; }
        public int StudentId { get; set; }
        public Student Student { get; set; }
    }

Columns

Entity Framework Core will create database columns for all the scalar properties in an entity class. The column name will be the same as the property name.

Column Data Type

The database columns' data type depends on the .NET type of the property and the database provider. For example, SQL Server maps string properties to nvarchar(max) and Int64 properties to bigint.

Primary Key

When Code First approach is used, EF Core doesn’t create a table without a primary key unless we explicitly specify it is a keyless entity. If a Model class contains a property named ID or <Entity Class Name>ID(case-insensitive), it will be considered the primary Key. Preference will be given to the property ID than <Entity Class Name>ID(case-insensitive) if both exist on the same class.

In the following classes, the StudentId and the Id fields will be considered as primary keys by convention.

  public class Student
    {
        //Here, EF core will consider StudentId property as the primary key. 
        public int StudentId { get; set; }
        public string Name { get; set; }
        
    }

  public class Student
    {
        //Here, EF core will consider Id property as the primary key. 
        public int Id { get; set; }
        public string Name { get; set; }
       
    }

Foreign Keys

Entity Framework considers a property as a foreign key when it has the same data type as the principal entity's (This is the entity that contains the primary/alternate key properties) primary key, and the name of the property follows one of these patterns. 

• <navigation property name><principal primary key property name>Id
• <principal class name><primary key property name>Id
• <principal primary key property name>Id

A navigation property is a property defined on the principal and/or dependent entity that references the related entity.

In the following example, navigational properties are there in both entities (Customer and DeliveryAddress) and a foreign key property (CustomerID) is defined in the DeiveryAddress table.

    public class Customer
    {     
        public int CustomerID { get; set; }
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public string Email { get; set; }
        public ICollection<DeliveryAdress> DeliveryAdresses { get; set; }
    }

 public class DeliveryAdress
    {
        public int DeliveryAdressId { get; set; }
        public String Address { get; set; }
        public bool PrimaryAddress { get; set; }
        public Customer Client { get; set; }
        //public int ClientCustomerID { get; set; }// This will be given first preference
        //public int CustomerCustomerID { get; set; }//This will be given second preference
        public int CustomerID { get; set; }//This will be given third preference
    }

Shadow Properties

EF Core generates shadow properties for dependent entities in relationships when no foreign key property is defined in the dependent entity. Consider the following example. 

    public class Customer
    {     
        public int CustomerID { get; set; }
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public string Email { get; set; }
        public ICollection<DeliveryAdress> DeliveryAdresses { get; set; }
    }

public class DeliveryAdress
    {       
        public int DeliveryAdressId { get; set; }
        public String Address { get; set; }
        public bool PrimaryAddress { get; set; }   

    }

Here, even if CustomerID property is not present in the DeliveryAddress entity, EF Core will generate CustomerID field in the DeliveryAddress table. EF will introduce a shadow property when a relationship is discovered but no foreign key property is found in the dependent entity class. Shadow properties can also be configured using Fluent API.

Schema

When a relational database is used, Entity Framework Core will create all database objects in your database’s default schema (Eg. dbo in SQL server)

Indexes

Indexes can be created using data annotations in .NET 5.0. A clustered index is created for primary key properties. Entity Framework Core creates indexes for foreign key properties also.