[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
EF Core intentionally uses a code-based model configuration approach, as opposed to an XML approach. There are many reasons to this:
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.
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: