¿Las interfaces fluidas son más flexibles que los atributos y por qué?

14

En un tutorial de EF 4.1 Code First se proporciona el siguiente código:

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

Luego se explica que la interfaz fluida es más flexible:

  

Las anotaciones de datos son definitivamente fáciles de usar, pero es preferible   Utilice un enfoque programático que ofrezca mucha más flexibilidad.

Luego se da el ejemplo de usar la interfaz 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);
}

No puedo entender por qué la interfaz fluida es supuestamente mejor. ¿Es realmente? Desde mi perspectiva, parece que las anotaciones de los datos son más claras y tienen una sensación semántica más clara.

Mi pregunta es ¿por qué una interfaz fluida sería una mejor opción que usar atributos, especialmente en este caso?

(Nota: soy bastante nuevo en todo el concepto de interfaces fluidas, por lo tanto, no espere saberlo previamente)

Referencia: enlace

    
pregunta Tjaart 01.08.2012 - 16:19

4 respuestas

12

Las anotaciones de datos son estáticas, por ejemplo, esta declaración de método no puede cambiar en tiempo de ejecución:

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

La interfaz fluida puede ser dinámica:

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

sin mencionar que el código puede ser reutilizado entre propiedades.

    
respondido por el Garrett Hall 01.08.2012 - 19:21
8

No creo que esa afirmación deba aplicarse de manera amplia; Es muy específico para codificar primero. En Code First, las anotaciones de datos incluyen solo un subconjunto de la funcionalidad que está disponible en la API fluida. En otras palabras, hay ciertas configuraciones de modelo que solo se pueden hacer usando la API fluida.

Por ejemplo, aquí hay algunas de las cosas que no se pueden especificar mediante las anotaciones:

  • La precisión de una propiedad DateTime
  • La precisión y la escala de las propiedades numéricas
  • Una propiedad de cadena o binaria de longitud fija
  • Una propiedad de cadena como no unicode
  • El comportamiento de eliminación de las relaciones
  • Estrategias de mapeo avanzadas

Personalmente, tiendo a usar las anotaciones de datos relacionadas con la validación siempre que sea posible, ya que otras tecnologías como MVC también pueden aprovecharlas. Para todo lo demás, prefiero la API fluida.

    
respondido por el bricelam 02.08.2012 - 00:05
1

La respuesta a su pregunta se encuentra en el enlace.

  

Luego, define las restricciones aplicables a su dominio dentro de este método mediante programación.

Básicamente, es más o menos preferido utilizar el enfoque de Atributos vs programático, donde el enfoque programático tiene más control sobre la entidad. Sin embargo, hay una forma personalizada de agregar atributos para decorar tu modelo que también puedes ver.

  

Al utilizar este enfoque, incluso puede describir las relaciones entre tablas y columnas.   En pocas palabras, si está dispuesto a tener más control de grano fino sobre su dominio, puede utilizar este nuevo enfoque que viene con EF4.1.

Sin embargo, para escenarios comunes de validación aplicando Atributos debería funcionar bien porque es robusto para cubrir la mayoría de los casos; y además puede ahorrarle tiempo.

    
respondido por el EL Yusubov 01.08.2012 - 16:35
0

Mi pensamiento es que recomiendan la API fluida para las implementaciones del código primero porque describe explícitamente cómo se crean las relaciones en la base de datos. Si utiliza anotaciones de datos, es posible que la base de datos creada por Entity Framework no sea la esperada. Su ejemplo inicial es muy simple, así que, como usted, solo usaría el método de anotación de datos.

    
respondido por el str8killinit 01.08.2012 - 16:53

Lea otras preguntas en las etiquetas