What is the difference between Data Annotations and Fluent API?

  

What's 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 namespace System.ComponentModel.DataAnnotations when the developer issues the data domain composition rules. That is, the two are not comparable, strictly speaking.

The question would be something like "what's the difference between the Fluent API and the decorating model using attributes?" (then, speaking of Data Annotations ).

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

  

Are there any restrictions between one or the other? Improve performance or are they just two ways to do the same?

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

The Fluent API is considering a more advanced feature, with some extra features, as Microsoft itself admits that it is not possible to express all configuration types with only attribute decoration . Some examples:

• Turn off cascading exclusion:

  .WillCascadeOnDelete(false)
  

• N for N without explicitly naming a Model setting 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 Model property for this (not recommended, but you can do it):

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

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

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

• Inheritance specification 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 Fluent API is a more complex and verbose feature than attribute decoration. In addition, misuse of the Fluent API can cause cohesion problems. Nothing prevents you from specifying on your system the set of Models entirely separate from the mappings.

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

The attribute mechanism 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. Neither could be different, the syntax of attributes does not allow much expressivity.

A mechanism that allows freer syntax, allows things to be dynamically resolved, and generates a more complex object tends to be more flexible, allowing you to do what was unthinkable with% s of% s. Remember that we are comparing a declarative form of metadata with an imperative form of code, you can not compare.

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

They chose to have the API syntax fluently, even by limiting the syntax of the language, it did not have to be that way if language was more powerful. What matters is the ability to express what you want.

I've always found this way better and never understood why they both used attributes.

But ASP.Net MVC benefits from data annotation, so it's something to think about. A pity to have been created that way.

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

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

Fluent API you can separate the liability that was previously bound in the domain layer in 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 there is no change, but both do the same thing I usually use Fluent API.