![]() So it’s much better to just start there in the first place.įinally. 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. 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. 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. 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. 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. Which one is correct? Well actually both! But I always push for Fluent Configurations and here’s why. Protected override void OnModelCreating(ModelBuilder modelBuilder)
0 Comments
Leave a Reply. |