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 utilizar un enfoque programático que brinde mucha más flexibilidad.
Luego se da el ejemplo de uso de 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 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, así que no espere ningún conocimiento previo sobre esto).
Referencia: http://codefirst.codeplex.com/
fuente
Respuestas:
Las anotaciones de datos son estáticas, por ejemplo, esta declaración de método no puede cambiar en tiempo de ejecución:
La interfaz fluida puede ser dinámica:
sin mencionar que el código se puede reutilizar entre propiedades.
fuente
No creo que esa declaración deba aplicarse ampliamente; Es muy específico de Code First. 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, estas son algunas de las cosas que no se pueden especificar utilizando las anotaciones:
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.
fuente
La respuesta a su pregunta se proporciona en el enlace.
Básicamente, es más o menos preferible usar Atributos versus enfoque programático, donde el enfoque programático tiene más control sobre la entidad. Sin embargo, existe una forma personalizada de agregar atributos para decorar su modelo que también puede verse.
Sin embargo, para escenarios comunes de validación, la aplicación de Atributos debería funcionar bien porque es robusta para cubrir la mayoría de los casos; Además, puede ahorrarle tiempo.
fuente
Mi opinión es que recomiendan la API fluida para las implementaciones de código primero porque usted describe explícitamente cómo se crean las relaciones en la base de datos. Si usa anotaciones de datos, la base de datos creada por Entity Framework puede no ser lo que espera. Su ejemplo inicial es muy simple, así que, como usted, simplemente usaría el método de anotación de datos.
fuente