Efcore: Making method names more self-explanatory in DbContext

[nefcanto]

Hi

Based on your documentation:

With EF Core, data access is performed using a model. A model is made up of entity classes and a context object that represents a session with the database, allowing you to query and save data.

We can say that in EF Core Model = DbContext + Entity Classes

Also to configure DbContext and Entity Classes we use different methods. Here's how:

• DbContext
  
  
  
  • OnConfiguring(DbContextOptionsBuilder optionsBuilder)
  
  
• Entity Classes
  
  
  
  • Fluent API
    
    
    
    
    
    • OnModelCreating(ModelBuilder modelBuilder)
    
    
    
  
  
  • Data Annotations (attributes)
  
  

This is not intuitive to me as a learner. And since I'm also a teacher myself, I find them difficult to teach to my students. Because they are not in harmony with definitions and documentations. Thus I recommend renaming these methods as follow:

1. Since OnConfiguring is a method that is used only to configure DbContext, thus I recommend renaming its name and its parameter's name to: OnConfiguringDatabaseContext(DbContextConfigurationBuilder builder). This explicitly tells EF Core developers that "hey, this method is ONLY to configure DbContext. If you want to configure your Entity Classes, don't use this method". By using configuration, instead of option, it also explicitly states that "hey, we're talking about configuration that is opposite to convention." Option is a choice. Configuration is a philosophy. Also if the name of the method is "to configure" thus the name of the parameter should be "configuration builder". This is harmonious and more intuitive.

2. Since model is created from entity classes AND database context, thus it's also counter-intuitive to be able to only configure entity classes in a method that is called OnModelCreating. As a learner, based on the block-diagram of a model I expect to be able to configure database context in this method too. But ModelBuilder has no methods to configure database context. Thus I recommend renaming it to OnConfiguringEntityClasses(EntityClassConfigurationBuilder builder). This explicitly tells EF Core developers that "hey, this is only used to configure part of the model, that is, entity classes. If you want to configure database context, we have another method for it".

A sample of the C# code:

public class BlogContext : DbContext
{
    public DbSet<Blog> Blogs { get; set; }

    protected override void OnConfiguringDatabaseContext(DbContextConfigurationBuilder builder)
    {
        builder.UseSqlServer("data source=.; initial catalog=Blog; integrated security=true;");
    }

    protected override void OnConfiguringEntityClasses(EntityClassConfigurationBuilder builder)
    {
        builder.Entity<Blog>().Property("Name").IsRequired();
    }
}

Thank you so much for this awesome ORM.

[roji]

@nefcanto without discussing whether your naming proposals are better than the current names, these methods have been there for a very long time. If we change them, that would produce a massive breaking change to every EF Core application out there, and would change a well-known and established vocabulary for all users.

[ajcvickers]

@nefcanto To add to what @roji said, I suspect the real issue here is that this:

"With EF Core, data access is performed using a model. A model is made up of entity classes and a context object that represents a session with the database, allowing you to query and save data.

Is not really accurate. Conceptually, the session is separate from the model. The DbContext contains mechanisms to build a model, and the resulting model can be used by multiple DbContext sessions.

With regards to the names, even if we could change them, I don't think we would go in the direction you suggest. OnConfiguring is intentionally not further qualified because it is a method on the DbContext for configuring the DbContext.

OnModelCreating on the other hand, is called when the context is building the model, which is conceptually different from configuring the context, and uses Model in the name because, while this is a method on the context, it is specifically for model configuration, not configuration of the context.