As interfaces fluentes são mais flexíveis que os atributos e por quê?

Em um tutorial do primeiro código EF 4.1, é fornecido o seguinte código:

public class Department
{
    public int DepartmentId { get; set; }
    [Required]
    public string Name { get; set; }
    public virtual ICollection<Collaborator> Collaborators { get; set; }
}

Em seguida, é explicado que a interface fluente é mais flexível:

As anotações de dados são definitivamente fáceis de usar, mas é preferível usar uma abordagem programática que ofereça muito mais flexibilidade.

O exemplo do uso da interface fluente é então dado:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Department>().Property(dp => dp.Name).IsRequired();
    modelBuilder.Entity<Manager>().HasKey(ma => ma.ManagerCode);
    modelBuilder.Entity<Manager>().Property(ma => ma.Name)
        .IsConcurrencyToken(true)
        .IsVariableLength()
        .HasMaxLength(20);
}

Não consigo entender por que a interface fluente é supostamente melhor. É realmente? Na minha perspectiva, parece que as anotações de dados são mais claras e têm uma sensação semântica mais clara.

Minha pergunta é por que uma interface fluente seria uma opção melhor do que usar atributos, especialmente neste caso?

(Nota: sou bastante novo em todo o conceito de interfaces fluentes; portanto, não espere conhecimento prévio sobre isso).

Referência: http://codefirst.codeplex.com/

As anotações de dados são estáticas, por exemplo, esta declaração de método não pode ser alterada em tempo de execução:

  [MinLength(5)]
  [MaxLength(20,ErrorMessage="Le nom ne peut pas avoir plus de 20 caractères")]
  public new string Name { get; set; }

A interface fluente pode ser dinâmica:

   if (longNamesEnabled)
   {
      modelBuilder.Entity<Manager>().Property(ma => ma.Name)
        .HasMaxLength(100);
   }
   else
   {
      modelBuilder.Entity<Manager>().Property(ma => ma.Name)
        .HasMaxLength(20);
   }

para não mencionar o código pode ser reutilizado entre propriedades.

Não acho que essa declaração deva ser aplicada de maneira ampla; é muito específico para o Code First. No Code First, as anotações de dados incluem apenas um subconjunto da funcionalidade disponível na API fluente. Em outras palavras, existem certas configurações de modelo que só podem ser feitas usando a API fluente.

Por exemplo, aqui estão algumas das coisas que não podem ser especificadas usando as anotações:

• A precisão de uma propriedade DateTime
• A precisão e a escala das propriedades numéricas
• Uma propriedade String ou Binary como comprimento fixo
• Uma propriedade String como não unicode
• O comportamento ao excluir dos relacionamentos
• Estratégias avançadas de mapeamento

Pessoalmente, costumo usar as anotações de dados relacionadas à validação sempre que possível, pois outras tecnologias como o MVC também podem tirar proveito delas. Para todo o resto, prefiro a API fluente.

A resposta à sua pergunta é fornecida no link.

Em seguida, defina suas restrições aplicáveis ​​ao seu domínio dentro deste método programaticamente.

Basicamente, é mais ou menos preferência usar Atributos versus abordagem programática, em que a abordagem programática tem mais controle sobre a entidade. No entanto, existe uma maneira personalizada de adicionar Atributos para decorar seu modelo que você também deve ter.

Ao usar essa abordagem, você pode até descrever as relações entre tabelas e colunas. Resumindo, se você deseja ter um controle mais refinado sobre seu domínio, pode usar esta nova abordagem que vem com o EF4.1.

No entanto, para cenários comuns de validação, a aplicação de Atributos deve funcionar bem, pois é robusta para cobrir a maioria dos casos; Além disso, você pode economizar tempo.

Meu pensamento é que eles recomendem a API fluente para as primeiras implementações de código, porque você descreve explicitamente como os relacionamentos são criados no banco de dados. Se você usar anotações de dados, o banco de dados criado pelo Entity Framework pode não ser o que você espera. Seu exemplo inicial é muito simples, então, como você, eu usaria apenas o método de anotação de dados.