Entity Framework CodeFirst - To decorate or not to decorate

Question

When doing the CodeFirst approach, there are two ways to declare keys and related tables.

public class Person
{
    [Key]
    public int Id { get; set; }
}

OR

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
    base.OnModelCreating(modelBuilder);

    modelBuilder.Entity<Person>().HasKey(e => e.Id);
}

Is this a matter of preference or does it make sense to use one over the other? What should be used in a fresh project?

Update: I will have around 8 entities each with around 1-4 relations and I want to allow cascade delete.

They both have their advantages. The attributes have as their advantage that EF-agnostic code can make use of them too, using reflection. The model builder has as its advantage that more aspects can be expressed, and if you need anything that doesn't have a usable attribute, you can still keep the various configuration bits together. Which is best, without further details, is therefore mainly a matter of opinion and taste. Is there any part of your question that won't get opinion-based answers, and can you focus your question on just that? — , Dec 29 '13 at 10:48
possible duplicate of [EF5 Code First - Data Annotations vs Fluent API](http://stackoverflow.com/questions/18055532/ef5-code-first-data-annotations-vs-fluent-api) — Gert Arnold, Dec 29 '13 at 20:45

Brett Postin · Accepted Answer · 2013-12-29T10:57:02.613

The first approach (data annotations) has only a subset of the capabilities of the second approach (fluent API).

Data annotations can pollute your model classes, whereas the fluent API allows you to separate that logic out in your DbContext, or even into a separate EntityTypeConfiguration class if you wish.

I personally prefer to keep my POCOs clean and leave those details out of my models so tend to opt for using the fluent API.

score 2 · Answer 2 · answered Dec 29 '13 at 11:15

As said yet, you have more capabilities when you use the Fluent API (second approach). For the primary key it does not matter where you define it. You should do it as you personally prefer. For such simple things like the key i personally prefer to define it on the POCO, because it makes my DbContext be smarter. If I have 100 POCO's, then I have only 100 lines of code to define the key. But on the other way, you have all your definition in one single place.

But what I would have a look at, is convention over configuration. In your case, you don't have to define the key. By convention the property called Id or PersonId which is an int, long or Guid, is automatically set as the primary key.

Selman Genç · Answer 3 · 2013-12-30T19:43:33.570

To set a primary key, it doesn't matter.(ofc. if you don't want to set composite primary key) But to do more complex jobs and configure all settings, you should use Fluent API. For example, you can't set cascade Delete to False with attributes. You can't configure third table names in many-to-many relationships with attributes.Also you can't change default functionality on relationships with attributes. To do all of this and more you can use Fluent API.

Entity Framework CodeFirst - To decorate or not to decorate

3 Answers3