Day 3: Domain Models and More

All roads lead to Rome.

This applies to so many cases in the realm of coding. While I was studying, I realized that some things could be made using two methods; Data Annotation and Fluent API. In my examples, I am using Fluent API. But, why is that? It is because allows for more control and flexibility when configuring the needed models.

1. Three Ways to Work with Domain Models in Entity Framework

1. Let’s create a class and call it Post and put it inside the Models folder that we created earlier. It should have four properties: Id, Title, Content, and Blog. Just like a real post! Blog here is now connected to Post.

 public class Post
 {
     public int Id { get; set; }
     public string Title { get; set; }
     public string Content { get; set; }
    //navigation property
     public Blog Blog { get; set; }

 }

2. Then, inside our Blog class, add a new property. The class should look like this:

 public class Blog
 {
     public int Id { get; set; }
     public string Url { get; set; }

     //new thing
     public List <Post> Posts { get; set; }

 }

This way every Blog could have many Posts!

Now, use the command **add-migration addPosts**. You are able to see in the new migration that the Posts are connected to the Blog via foreign key.

If you look closely at the new migration, you’ll find this line:

onDelete: ReferentialAction.Cascade

This means that if a parent is deleted, its children are also deleted . It’s better to change the word Cascade to Restrict to prevent deleting entities that have children. The child must be deleted first, then the parent.

Create a class and call it AuditEntry and put in the Models Folder. This is what it should look like:

 public class AuditEntry
 {
     public string Id {  get; set; }
     public string Username { get; set; }
     public string Action { get; set; }
 }

But, how can we make it a domain class?

The answer is pretty straightforward. Remember the OnModelCreating function in the ApplicationDbContext class? Yes, we are going to use this function a lot today. After adding this line, AuditEntry has now become a Domain Class.

 modelBuilder.Entity<AuditEntry>();

Now, remove the migration, because we don’t want to apply the last change to the database and add-migration addPosts again. You will find that two tables have been created: AuditEntry and Post.

To sum things up, there are three ways approaches to defining domain models in EF Core are:

1. Using DbSet

 public DbSet<Blog> Blogs { get; set; }

2. Using navigation property

public Blog Blog { get; set; }

3. Using modelBuilder

modelBuilder.Entity<AuditEntry>();

2. Excluding Entities from Migrations and Database Schema in Entity Framework Core

Firstly, do not forget remove the last migration because we don’t need it in this scenario

In the *OnModelCreating function in ApplicationDbContext* class, use this line of code:

modelBuilder.Ignore<Post>();

Then, use add-migration RemovePosts for example to see the changes. Remove the migration to undo. This ensures Post is excluded from the database schema or the migration. This completely removes the Post from the EF Core model.

The following piece of code keeps the Blog in the EF Core and map Blog to the Blogs table. However, it will be excluded from Migrations.

      modelBuilder.Entity<Blog>()
                  .ToTable("Blogs", b => b.ExcludeFromMigrations());

3. How Do I Change a Table’s Name?

No, it’s not. We can still change it.

What if we have a class with a certain name and we want a table of this class to be mapped to database with a different name? That is absolutely fine.

Use the command add-migration changeTableTitle. Type in the following code:

 modelBuilder.Entity<Post>().ToTable("MyPosts");

The last code was used in Step 2 , but it was excluded from migrations.

4. Choosing the Schema

I know we have been using the modelBuilder parameter in the ApplicationDbContext class a lot today, but it’s going to be our right hand man.

To change the schema, you need two parameters: the name of the table and the name of the schema

  modelBuilder.Entity<Post>().ToTable("Posts",schema:"blogging");

But, how do we avoid assigning blogging as a schema each time and make it our default schema? You can do so using this line:

modelBuilder.Entity<Post>().HasDefaultSchema("blogging");

5. Mapping a Domain Model to a View

In order to map a domain model to a view, you need two parameters: the name of the domain model and the view (obviously).

modelBuilder.Entity<Post>().ToView("SelectPosts",schema:"blogging");

6. Excluding Properties

In the Blog class, add a new public property called SubmittedOn :

     public DateTime SubmittedOn { get; set; }

Add this line of code to the OnModelCreating function:

 modelBuilder.Entity<Blog>().Ignore(b => b.SubmittedOn);

Use add-migration SumbittedOnToBlogs. If you actually apply the migration, use the update-database command.

But, why would we exclude properties? Sometimes, we need to compute things and these things are derived properties. In other cases, they are just temporary. And, those are just a couple of examples.

Today, we learned how to work with domain models and change things that are concerned with our schema. Next time, we will be more in depth in the world of Entity Framework.