Czy płynne interfejsy są bardziej elastyczne niż atrybuty i dlaczego?

W samouczku dotyczącym kodu EF 4.1 podano następujący kod:

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

Następnie wyjaśniono, że płynny interfejs jest bardziej elastyczny:

Adnotacje danych są zdecydowanie łatwe w użyciu, ale lepiej jest zastosować podejście programowe, które zapewnia znacznie większą elastyczność.

Podano przykład użycia płynnego interfejsu:

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);
}

Nie rozumiem, dlaczego płynny interfejs jest podobno lepszy. Czy to naprawdę Z mojego punktu widzenia wygląda na to, że adnotacje danych są bardziej wyraźne i mają bardziej czysty semantyczny charakter.

Moje pytanie brzmi: dlaczego płynny interfejs byłby lepszym rozwiązaniem niż używanie atrybutów, szczególnie w tym przypadku?

(Uwaga: Jestem całkiem nowy w całej koncepcji płynnych interfejsów, więc proszę nie oczekiwać wcześniejszej wiedzy na ten temat.)

Odniesienie: http://codefirst.codeplex.com/

Adnotacje danych są statyczne, na przykład ta deklaracja metody nie może się zmienić w czasie wykonywania:

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

Płynny interfejs może być dynamiczny:

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

nie wspominając o tym, że kod może być ponownie użyty między właściwościami.

Nie sądzę, aby to stwierdzenie powinno być szeroko stosowane; jest to bardzo specyficzne dla Code First. W Code First adnotacje danych zawierają tylko podzbiór funkcji dostępnych w płynnym interfejsie API. Innymi słowy, istnieją pewne konfiguracje modeli, które można wykonać tylko przy użyciu płynnego interfejsu API.

Oto na przykład niektóre rzeczy, których nie można określić za pomocą adnotacji:

• Precyzja właściwości DateTime
• Precyzja i skala właściwości numerycznych
• Ciąg lub właściwość binarna jako stała długość
• Właściwość String jako non-Unicode
• Zachowanie relacji podczas usuwania
• Zaawansowane strategie mapowania

Osobiście staram się używać adnotacji związanych z walidacją, gdy tylko jest to możliwe, ponieważ inne technologie, takie jak MVC, również mogą z nich korzystać. Do wszystkiego innego wolę płynne API.

Odpowiedź na twoje pytanie znajduje się w linku.

Następnie programowo definiujesz ograniczenia obowiązujące w Twojej domenie.

Zasadniczo preferuje się stosowanie Atrybutów zamiast podejścia programowego, przy czym podejście programowe ma większą kontrolę nad jednostką. Istnieje jednak niestandardowy sposób dodawania atrybutów w celu udekorowania modelu, który również możesz wyglądać.

Korzystając z tego podejścia, możesz nawet opisać relacje między tabelami i kolumnami. Podsumowując, jeśli chcesz mieć większą kontrolę nad swoją domeną, możesz zastosować to nowe podejście, które jest dostarczane z EF4.1.

Jednak w typowych scenariuszach sprawdzania poprawności zastosowanie atrybutów powinno działać dobrze, ponieważ jest odporne na większość przypadków; a ponadto może zaoszczędzić czas.

Myślę, że zalecają płynny interfejs API dla pierwszych implementacji kodu, ponieważ wyraźnie opisujesz sposób tworzenia relacji w bazie danych. Jeśli używasz adnotacji danych, baza danych utworzona przez Entity Framework może nie być tym, czego oczekujesz. Twój początkowy przykład jest bardzo prosty, więc podobnie jak ty, użyłbym tylko metody adnotacji danych.