In a EF 4.1 Code First tutorial the following code is given:
public class Department
{
public int DepartmentId { get; set; }
[Required]
public string Name { get; set; }
public virtual ICollection<Collaborator> Collaborators { get; set; }
}
Then it is explained that the fluent interface is more flexible:
Data Annotations are definitely easy to use but it is preferable to
use a programmatic approach that provides much more flexibility.
The example of using the fluent interface is then given:
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);
}
I can’t understand why the fluent interface is supposedly better. Is it really? From my perspective it looks like the data annotations are more clear, and have more of a clean semantic feel to it.
My question is why would a fluent interface be a better option than using attributes, especially in this case?
(Note: I’m quite new to the whole concept of fluent interfaces, so please expect no prior knowledge on this.)
Reference: http://codefirst.codeplex.com/
2
Data annotations are static, for instance this method declaration cannot change at runtime:
[MinLength(5)]
[MaxLength(20,ErrorMessage="Le nom ne peut pas avoir plus de 20 caractères")]
public new string Name { get; set; }
The fluent interface can be dynamic:
if (longNamesEnabled)
{
modelBuilder.Entity<Manager>().Property(ma => ma.Name)
.HasMaxLength(100);
}
else
{
modelBuilder.Entity<Manager>().Property(ma => ma.Name)
.HasMaxLength(20);
}
not to mention the code can be reused between properties.
7
I don’t think that statement should be broadly applied; it is very specific to Code First. In Code First, data annotations include only a subset of the functionality that is available in the fluent API. In other words, there are certain model configurations that can only be done using the fluent API.
For example, here are some of the things that can’t be specified using the annotations:
- The precision of a DateTime property
- The precision and scale of numeric properties
- A String or Binary property as fixed-length
- A String property as non-unicode
- The on-delete behavior of relationships
- Advanced mapping strategies
Personally, I tend to use the validation-related data annotations whenever possible since other technologies like MVC can also take advantage of these. For everything else, I prefer the fluent API.
4
Answer to your question is provided in the link.
Then you define your constraints applicable to your domain within this method programmatically.
Basically, it is more or less preference to use Attributes vs programmatic approach, where programmatic approach has more control over the entity. However, there a custom way of adding Attributes to decorate your model that you may look as well.
When using this approach you may even describe relations between tables and columns.
Bottom line, if you are willing to have more fine-grain control over your domain you may use this new approach that comes with EF4.1.
However, for common scenarios of validation applying Attributes should work fine because it is robust to cover most cases; and in addition it might save you time.
5
My thought is that they recommend the fluent API for code first implementations because you explicitly describe how the relationships are created in the database. If you use data annotations the database created by Entity Framework may not be what you expect. Your initial example is very simple so, like you, I would just use the data annotation method.
1