What is the difference between Data Annotations and Fluent API?

Question

What is the difference between Data Annotations and Fluent API?

Is there a restriction between one or the other? Improve performance or are just two ways to do the same thing?

Answer 1

What is the difference between Data Annotations and Fluent API?

The approach mainly but there is a conceptual problem in your question because the Fluent API makes use of the namespace System.ComponentModel.DataAnnotations when the programmer sets out the rules for the composition of the data domain. That is, the two are not comparable, strictly speaking.

The question would be something like "what is the difference between the Fluent API and the model by decoration using attributes?" (there yes, speaking of Data Annotations).

Still talking about the approach, we have that decoration by attributes acts on classes that represent Models and its properties, while the Fluent API acts on a more global level, enunciating rules directly in the context of application data.

Is there a restriction between one or the other? Improve performance or are just two ways to do the same thing?

When using both resources, it is recommended not to express the same rules twice, as this may confuse the Entity Framework and cause errors. I think that would be the closest restriction on the use of both.

The Fluent API is considered a more advanced feature, with some extra features, since it Microsoft itself admits that it is not possible to express every type of configuration with decoration by attributes only. Some examples:

• Disconnect Cascade Exclusion:

  .WillCascadeOnDelete(false)
  

• Association N to N without specifying a Model defining the association (not very recommended):

  modelBuilder.Entity<Produto>() 
              .HasMany(p => p.Lojas) 
              .WithMany(l => l.Produtos) 
              .Map(m => 
              { 
                  m.ToTable("ProdutosLojas"); 
                  m.MapLeftKey("ProdutoId"); 
                  m.MapRightKey("LojaId"); 
              });
  

• Specify foreign key if it is not desirable to use a property in Model for this (not very recommended, but you can do):

  .Map(conf => conf.MapKey("ChaveEstrangeiraId"))
  

• Fine-tuning of the database, especially in cases where only one side of the association is exposed in the Model (which is problematic, but can be done):

  .WithMany(...)
  .WithOptional(...)
  .WithRequiredDependent(...)
  .WithRequiredPrincipal(...)
  

• Specification of inheritance between Model and database (Table by Hierarchy, Table by Type, Table by Concrete Class):

  .Map<TDerivado>(Action<EntityMappingConfiguration<TDerivado>> ...)
  

It is important to note that the Fluent API is a more complex and verbose feature than attribute decoration. Also, misuse of the Fluent API can cause cohesion problems. Nothing prevents you from specifying in your system the set of Models completely separate from the mapping.

If you allow me a recommendation, the Fluent API should be used for cases where attribute decoration does not meet.

Answer 2

The mechanism of attribute has always been very limited. It is solved all in compilation and used with reflection, which prevents doing much.

In addition, the annotations available in the Entity Framework are limited, you can do the basics, but it’s not very flexible. Nor could it be different, the attributes syntax does not allow much expressiveness.

A mechanism that allows a more free syntax, allows to solve things dynamically and that generates a more complex object tends to be more flexible, allowing to accomplish what was unthinkable with the dataannotations. Remember that we are comparing a declarative form of metadata with an imperative form of code, it is not possible to compare.

For all this there are more options available in the fluent API.

They actually chose the API to have a fluent syntax, even by limiting the syntax of the language, it didn’t have to be this way if the language was more powerful. What matters is the ability to express what you want.

I always found this way better and never understood why so many used attributes.

But ASP.NET MVC benefits from data annotation, so it’s something to think about. A shame it was created like this.

I have not tested and I cannot be sure, intuitively I believe that the fluent API is faster because it is a specific and more concrete mechanism than the attribute that is too abstract and general a mechanism.

Answer 3

Using Data Annotations you create a certain coupling in letting an entity coupled to a technology.

Fluent API you can separate the responsibility that was previously coupled in the domain layer into another layer. Example: I map the Fluent API to the Data Access Layer (DAL) by isolating the domain layer.

In terms of performance I believe that there is no change, but both do the same thing I always use Fluent API.