Les interfaces fluides sont-elles plus flexibles que les attributs et pourquoi?

Dans un didacticiel EF 4.1 Code First, le code suivant est fourni:

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

Ensuite, il est expliqué que l'interface fluide est plus flexible:

Les annotations de données sont certainement faciles à utiliser, mais il est préférable d'utiliser une approche programmatique qui offre beaucoup plus de flexibilité.

L'exemple d'utilisation de l'interface fluide est alors donné:

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

Je ne comprends pas pourquoi l'interface fluide est censée être meilleure. Est ce que c'est vraiment? De mon point de vue, il semble que les annotations de données soient plus claires et plus sémantiques.

Ma question est pourquoi une interface fluide serait-elle une meilleure option que l'utilisation d'attributs, en particulier dans ce cas?

(Remarque: je suis assez nouveau dans le concept d'interfaces fluides, alors ne vous attendez à aucune connaissance préalable à ce sujet.)

Référence: http://codefirst.codeplex.com/

Les annotations de données sont statiques, par exemple, cette déclaration de méthode ne peut pas changer au moment de l'exécution:

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

L'interface fluide peut être dynamique:

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

sans oublier que le code peut être réutilisé entre les propriétés.

Je ne pense pas que cette déclaration devrait être largement appliquée; il est très spécifique à Code First. Dans Code First, les annotations de données incluent uniquement un sous-ensemble des fonctionnalités disponibles dans l'API fluide. En d'autres termes, certaines configurations de modèle ne peuvent être effectuées qu'à l'aide de l'API courante.

Par exemple, voici certaines choses qui ne peuvent pas être spécifiées à l'aide des annotations:

• La précision d'une propriété DateTime
• La précision et l'échelle des propriétés numériques
• Une propriété String ou Binary de longueur fixe
• Une propriété String non-unicode
• Le comportement à la suppression des relations
• Stratégies de cartographie avancées

Personnellement, j'ai tendance à utiliser les annotations de données liées à la validation chaque fois que possible, car d'autres technologies comme MVC peuvent également en profiter. Pour tout le reste, je préfère l'API couramment.

La réponse à votre question est fournie dans le lien.

Ensuite, vous définissez vos contraintes applicables à votre domaine dans cette méthode par programme.

Fondamentalement, il est plus ou moins préférable d'utiliser Attributs vs approche programmatique, où l'approche programmatique a plus de contrôle sur l'entité. Cependant, il existe un moyen personnalisé d'ajouter des attributs pour décorer votre modèle que vous pouvez également regarder.

Lorsque vous utilisez cette approche, vous pouvez même décrire les relations entre les tables et les colonnes. En fin de compte, si vous souhaitez avoir un contrôle plus précis sur votre domaine, vous pouvez utiliser cette nouvelle approche fournie avec EF4.1.

Cependant, pour les scénarios courants de validation, l' application des attributs devrait fonctionner correctement car elle est robuste pour couvrir la plupart des cas; et en plus cela pourrait vous faire gagner du temps.

Je pense qu'ils recommandent l'API courante pour les premières implémentations de code parce que vous décrivez explicitement comment les relations sont créées dans la base de données. Si vous utilisez des annotations de données, la base de données créée par Entity Framework peut ne pas être celle que vous attendez. Votre exemple initial est très simple, donc, comme vous, j'utiliserais simplement la méthode d'annotation des données.