Efcore: [Proposal] Make fluent API more fluent

Created on 30 Apr 2020  路  3Comments  路  Source: dotnet/efcore

[Proposal] Make fluent API more fluent
Take this as an example:
```C#
modelBuilder.Entity()
.Property(s => s.StudentId)
.HasColumnName("Id")
.HasDefaultValue(0)
.IsRequired();

    modelBuilder.Entity<Student>()
        .HasOne<Grade>(s => s.Grade)
        .WithMany(g => g.Students)
        .HasForeignKey(s => s.CurrentGradeId);
I suggest to use XML to rewrite it like this:
```XML
<Student>
      <StudentId ColumnName="Id" 
          DefaultValue="0" 
          Required />
      <Relation HasOne="Grade" 
         WithMany="Students" 
         ForeignKey="CurrentGradeId" /> 
</Student>

I think most of fluent API can be represented as an XML in a more compact and readable way. We can put it in a config file under the context class. Say: context1.vb.config

closed-not-needed customer-reported

Most helpful comment

EF Core intentionally uses a code-based model configuration approach, as opposed to an XML approach. There are many reasons to this:

  • Code-based configuration provides compile-time type safety - if you make a mistake in your configuration, the compiler won't compile it. With an XML approach errors are (usually) only discovered in runtime.
  • Providers can easily extend model configuration with extension methods. For SQL Server adds some special methods to the fluent API; doing a pluggable configuration model with XML (and again, one that can be validated at build-time) is really non-trivial.
  • We don't want to maintain two systems for model configuration (code and XML), as this has a large price. Note that we already allow some configuration to happen with data annotations (i.e. attributes).
  • Saying that your XML above is more fluent is mostly a matter of taste, many people would say the opposite.
  • As a general tendency, the world seems to have moved away from XML-based configuration approaches towards code-based configuration.

All 3 comments

EF Core intentionally uses a code-based model configuration approach, as opposed to an XML approach. There are many reasons to this:

  • Code-based configuration provides compile-time type safety - if you make a mistake in your configuration, the compiler won't compile it. With an XML approach errors are (usually) only discovered in runtime.
  • Providers can easily extend model configuration with extension methods. For SQL Server adds some special methods to the fluent API; doing a pluggable configuration model with XML (and again, one that can be validated at build-time) is really non-trivial.
  • We don't want to maintain two systems for model configuration (code and XML), as this has a large price. Note that we already allow some configuration to happen with data annotations (i.e. attributes).
  • Saying that your XML above is more fluent is mostly a matter of taste, many people would say the opposite.
  • As a general tendency, the world seems to have moved away from XML-based configuration approaches towards code-based configuration.

Sorry I forgot to mention, that this xml file should have intellisense and syntax chechs based on the context clas it belongs to. It is similar to razor files but no need for c# code at least for now. This means it is the exact fluent API but written in xml form.

@VBAndCs the point you are missing, is that the entities being configured in the model are actual .NET CLR types (classes), since EF Core does "code-first". While basic syntax/schema validation are easy for XML, it's very different to expect it to validate that it refers to actual .NET types and to actual properties within those types. The compiler does this naturally - best to configure code entities with... code. Also, Intellisense and syntax checks would be specific to Visual Studio, and would have to be reimplemented for each IDE, quite a lot of effort.

Razor files are not configuration - they are a true templating/markup language, which is quite a different scenario. Razor also isn't XML - it allows you to embed C# constructs via a special syntax. Also, Razor is quite a massive investment to maintain; of course, it's worth it - but the same can't be said of an EF Core XML model configuration.

In any case, there doesn't seem to be any value to reimplementing the entire model configuration API in XML - it's only a question of taste... Some other person may prefer JSON...

Am going to go ahead and close this, I hope I've given enough reason why the team chose to implement code-base configuration. If you've still got questions or ideas, feel free to continue posting here though.

Was this page helpful?
0 / 5 - 0 ratings