The Entity Framework is one of my favorite Object Relational Mapping Tools. It has extensive support for schema migrations, and change tracking and it also supports LINQ Queries.

It also works with one of my favorite SQL databases; SQLite.
What's there not to love about the Entity Framework Core? It is especially great when your want to focus on the application logic because EFC will automatically generate the SQL code for you.
What's there not to love about the Entity Framework Core? It is especially great when your want to focus on the application logic because EFC will automatically generate the SQL code for you.

In order to ensure that the Entity Framework Core generates accurate SQL code, you must have well-written model classes that clearly state the relationships between the entities

Let's get to the meat of this article

Relational Databases reduce duplication, let's say we have a Gym data records table that has athlete's, workouts, and personal trainers;
if the data is recorded in a non-relational approach we would have a long list of different Athletes that do the same Workouts, with the same Personal Trainer.

This means that if 50 Athletes attended a workout called Cardio, held by one personal trainer, we would have to record the workout classes and the personal trainer's name 50 times, God Forbid the Personal Trainer's name changes and now we must update the 50 duplicate occurrences.

Relational Databases have entities such as Athlete, Workout Plan, and Personal Trainer that relate to one another by Foreign Keys, and together they make managing data easier and less prone to errors

One-to-Many Relationships

One-to-many relationships look at two unique entities/tables for example a Personal-Trainer and a Workout Class

A single Personal Trainer can conduct multiple workout classes and that forms our one-to-many relationship.
To show this one-to-many relationship for the Entity Framework to generate our SQL code our Model classes should look like this:

The Personal Trainer Model creates a collection of Workout Model

 public class PersonalTrainer
    {
        public int Id { get; set; }
        public string Name { get; set; }
        public string Surname { get; set; }
        public ICollection<Workout> Workouts { get; set; }

    }

The Workout Model class declares the Foreign Key and adds a navigation property of Workout.

public class Workout
    {
        public int Id { get; set; }
        public string Title { get; set; }
        public int MetabollicEquivalent { get; set; }
        public int Duration { get; set; }
        public int PersonalTrainerId { get; set; }
        public PersonalTrainer PersonalTrainer { get; set; } 

A cheat method that I like to use

• First I create an Entity Diagram showing the one-to-many relationship

• The entity that is "One" always has a Collection of the "Many" entity

• The "Many" Entity will have a Foreign Key

Many-to-Many Relationships

Many-to-Many relationships are actually entities that have a one-to-many relationship between them both ways. For example a Workout can have multiple Athletes and Athletes can do multiple Workouts. This relationship is represented by creating a join table and then relating the entities to the join on a one-to-many relationship as follows:

Easy right!

Now to configure a model for such a relationship is just as simple:
The Athlete class will create a collection of the Join Table That We will create called AthleteWorkout

public class Athlete
    {
        public int ID { get; set; }
        public string Name { get; set; }
        public string Surname { get; set; }
        public decimal Weight { get; set; }
        public decimal Height { get; set; }
        public DateTime StartDate { get; set; }
        public ICollection<AthleteWorkout> AthleteWorkouts { get; set; }
    }

and Workout class will do the same

 public class Workout
    {
        public int Id { get; set; }
        public string Title { get; set; }
        public int MetabollicEquivalent { get; set; }
        public int Duration { get; set; }
        public int PersonalTrainerId { get; set; }
        public PersonalTrainer PersonalTrainer { get; set; } 

    }

Then the join table AthleteWorkout class will have the navigation properties of both Athlete and Workout and their Foreign Keys

public class AthleteWorkout
    {
        public int ID { get; set; }
        public int AthleteId { get; set; }
        public Athlete Athlete { get; set; }
        public int WorkoutId { get; set; }
        public Workout Workout { get; set; }
    }

Understanding how relationships work is fundamental when you have to create the joins and navigation properties of Models.

In the next article, I will look at how we configure the models that we created for our ApplicationDbContext class.