Le interfacce fluide sono più flessibili degli attributi e perché?

In una prima esercitazione sul codice EF 4.1 viene fornito il seguente codice:

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

Quindi viene spiegato che l'interfaccia fluida è più flessibile:

Le annotazioni sui dati sono sicuramente facili da usare, ma è preferibile utilizzare un approccio programmatico che offre molta più flessibilità.

Viene quindi fornito l'esempio dell'uso dell'interfaccia fluida:

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);
}

Non riesco a capire perché l'interfaccia fluida sia presumibilmente migliore. É davvero? Dal mio punto di vista, sembra che le annotazioni dei dati siano più chiare e abbiano una sensazione semantica più chiara.

La mia domanda è: perché un'interfaccia fluida sarebbe un'opzione migliore rispetto all'utilizzo degli attributi, specialmente in questo caso?

(Nota: sono piuttosto nuovo all'intero concetto di interfacce fluide, quindi per favore non aspettatevi conoscenze precedenti su questo.)

Riferimento: http://codefirst.codeplex.com/

Le annotazioni dei dati sono statiche, ad esempio questa dichiarazione del metodo non può cambiare in fase di esecuzione:

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

L'interfaccia fluida può essere dinamica:

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

per non parlare del codice che può essere riutilizzato tra le proprietà.

Non credo che tale affermazione debba essere ampiamente applicata; è molto specifico per Code First. In Code First, le annotazioni dei dati includono solo un sottoinsieme della funzionalità disponibile nell'API fluente. In altre parole, ci sono alcune configurazioni del modello che possono essere fatte solo usando l'API fluente.

Ad esempio, ecco alcune delle cose che non possono essere specificate usando le annotazioni:

• La precisione di una proprietà DateTime
• La precisione e la scala delle proprietà numeriche
• Una proprietà String o Binary come lunghezza fissa
• Una proprietà String come non unicode
• Il comportamento all'eliminazione delle relazioni
• Strategie di mappatura avanzate

Personalmente, tendo a utilizzare le annotazioni dei dati relative alla convalida ogni volta che è possibile poiché anche altre tecnologie come MVC possono trarne vantaggio. Per tutto il resto, preferisco l'API fluente.

La risposta alla tua domanda è fornita nel link.

Quindi definisci i tuoi vincoli applicabili al tuo dominio all'interno di questo metodo a livello di codice.

Fondamentalmente, è più o meno preferibile utilizzare Attributi rispetto all'approccio programmatico, in cui l'approccio programmatico ha un maggiore controllo sull'entità. Tuttavia, c'è un modo personalizzato di aggiungere attributi per decorare il tuo modello che potresti anche guardare.

Quando si utilizza questo approccio è anche possibile descrivere le relazioni tra tabelle e colonne. In conclusione, se si desidera avere un controllo più accurato sul proprio dominio, è possibile utilizzare questo nuovo approccio fornito con EF4.1.

Tuttavia, per gli scenari comuni di convalida l' applicazione degli attributi dovrebbe funzionare bene perché è affidabile per coprire la maggior parte dei casi; e inoltre potrebbe farti risparmiare tempo.

Il mio pensiero è che raccomandino l'API fluente per le prime implementazioni del codice perché descrivi esplicitamente come vengono create le relazioni nel database. Se si utilizzano annotazioni di dati, il database creato da Entity Framework potrebbe non essere quello previsto. Il tuo esempio iniziale è molto semplice, quindi, come te, userò semplicemente il metodo di annotazione dei dati.