It is easy to see which validation rule is related to which property because it is placed right above the property and it is quite self-explanatory.Data Annotationsįor the validation configuration, such as required or max length validation, you should always prefer the Data Annotations over Fluent API approach. It is quite easy to prepare this type of configuration and it is time-saving as well.
So, having the same class name as the table name, having a name for the primary key property that matches the naming convention and having the properties with the same name and type as the columns, should be our first choice. We should always start with the configuration by Convention. Since now we know three different configuration approaches it can get a bit confusing which one to use. Recommendations for Using EF Core’s Different Configuration ApproachesĮntity Framework Core does an awesome job in configuring our database by using the rules that we provide. NET/C# content and get paid? > JOIN US! <<
#Data annotations composite key code
Wanna join Code Maze Team, help us produce more awesome. Now, we can configure its default value via the Fluent API: modelBuilder.Entity() So, to configure a PrimaryKey property via the Data Annotations approach, we have to use the attribute: In these situations, we have to use either the Data Annotations approach or the Fluent API. But the naming convention won’t work if the name of the property doesn’t fit the naming convention or if we have a composite key in our entity. We have seen, in one of the previous sections, that EF Core automatically sets the primary key in the database by using the naming convention. PrimaryKey Configuration with Data Annotations and Fluent API But if we are ignoring a class, then the Ignore method is called with the modelBuilder object itself.
All the other methods are pretty self-explanatory.Īs you can see, if we are ignoring a property, then the Ignore method is chained directly to the Entity method, not on the Property method, as we did in a previous configuration. In the beginning, we are selecting the entity to configure and with the Property method, we are specifying which property we want to add the constraint on. NET/C# content and get paid? > JOIN US! () So, if for any reason we need to change a class name, the attribute would prove to be quite useful. But the attribute is going to override that. NET/C# content and get paid? > JOIN US! property is named Students in the ApplicationContext class. So, this means that the Name property can have a Null as a value (because the default value for a string type is null) but the Age cannot (because it is a value type):
When EF Core uses configuration by convention it will go through all the public properties and map them by their name and type. When using configuration by convention, the nullability of a column is based on the property type from our model class. Instead, we have to use either Data Annotations or Fluent API. If we have a composite key in our class, we can’t use the configuration by Convention. This means that property is going to be translated as a primary key in the database if it has an “ Id” property name or a combination + Id (as it is a case with our StudentId property): This approach can be overridden by using Data Annotations or Fluent API approach.Īs we already mentioned, EF Core configures the primary key field from our Student model class by following the naming convention. Configuration by convention means that EF Core will follow a set of simple rules on property types and names and configure the database accordingly.
0 kommentar(er)
