You can then put any configuration for this particular model you would have put inside the context, inside the Configure method. Public void Configure(EntityTypeBuilder builder) public class MyEntit圜onfiguration : IEntityTypeConfiguration It works like this.Ĭreate a class called Configuration and inherit from IEntityTypeConfiguration. What if you have 10 tables? 20 tables? 50? This class is going to quickly surpass hundreds if not thousands of lines and no amount of comments or #regions is going to make it more readable.īut there’s also a (seemingly) much less talked about feature called IEntityTypeConfiguration. Kinda like this : protected override void OnModelCreating(ModelBuilder modelBuilder) That’s great! But you’ll quickly find that all the tutorials tell you to just keep jamming everything into the “OnModelCreating” method of your Context. So if you’ve made it past the argument of Attributes vs Fluent and decided on Fluent. So it’s much better to just start there in the first place. Just a personal preferences.Īll rather weak arguments I know but honestly, before long, you will have to use Fluent Configuration for something. Then again, things like Active Record exist so it’s not a hard and fast rule. I think adding attributes to any POCO changes it from describing a data structure, to describing how that data structure should be saved. Maybe in the future I store this entity in a flat XML file. While it’s true that in this case, I’m building an entity to store in a SQL Database, that may not always be the case.
Model builder entity framework free#
When it gets to that point, it makes even less sense to have your configuration split across Attributes and Fluent.įinally, from a purely aesthetic stand point, I personally prefer my POCOs (Plain Old C# Objects) to be free of implementation details.
![model builder entity framework model builder entity framework](https://cdn-images-1.medium.com/max/1200/1*mtaArS7SvzjZVhtfJVeK2Q.png)
Microsoft themselves have come out and said that Fluent Configuration for EF Core is an “Advanced” feature, but I feel like anything more than just dipping your toe into EF Core, you’re gonna run into a dead end with Data Annotations and have to mix in Fluent Configuration anyway. Want to configure a complex HasMany relationship? DataAnnotations relationships are all about conventions so breaking that is extremely hard whereas in Fluent it’s a breeze. Complex index that spans two fields and adds another three as include columns? Not a problem in Fluent but no way to do it in DataAnnotations (Infact Indexes in general got ripped out of attributes and are only just now making their way back in with a much weaker configuration than just using Fluent ). The thing is, Fluent Configurations are *much* more powerful than Data Annotations. I mean, this one is true and I do see the point but as we are about to find out, complex configuration simple cannot be done with data annotations alone and therefore you’re still going to have to do rework anyway. So for example if you took an EF Core entity and switched to using another ORM, it may be able to just work out of the box with the same configurations.
![model builder entity framework model builder entity framework](http://images.pearsonclinical.com/images/ca/rti/images/RTI_triangle_med.jpg)
Many ORMs use this library to configure their data models. There’s also an argument that the attributes you use come from the DataAnnotations library from Microsoft. I get that sometimes a quick and dirty internal API might just pass models back and forth, between the database and the API, but the fact that attributes work for both is simply a coincidence not an actual intended feature.
![model builder entity framework model builder entity framework](https://www.webtrainingroom.com/blogimages/ef-core-dbcontext1.png)
You should always aim to have specific ViewModels returned from your API and not return out your entity models. There is an argument that when you use attributes like on a property, it also works if your model is being returned/created via an API.
![model builder entity framework model builder entity framework](https://i.stack.imgur.com/8HfHb.png)
Which one is correct? Well actually both! But I always push for Fluent Configurations and here’s why. So the first thing you notice when you pick up EF Core is that half the documentation tells you you can simply add an attribute to any entity to mark it as required : Īnd then the other half of the documentation tells you you should override the OnModelCreating inside your context and use “Fluent” configuration like so : protected override void OnModelCreating(ModelBuilder modelBuilder) Attribute (Data Annotations) vs Fluent Configuration Let’s do a quick dive and see what our options are and what gives us the cleanest result.
Model builder entity framework code#
By Entity Configurations, I mean doing a code first design and being able to mark fields as “Required”, or limit their length, or even create indexes on tables. And one of the things that catches me out is just how happy some developers are to make an absolute meal out of Entity Configurations with EF Core. Even with my love for Dapper these days, I often have to break out EF Core every now and again.