Akıcı arayüzler niteliklerden daha esnek mi ve neden?

EF 4.1 Kod İlkinde öğreticide aşağıdaki kod verilir:

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

Daha sonra akıcı arayüzün daha esnek olduğu açıklanmıştır:

Veri Ek Açıklamalarının kullanımı kesinlikle kolaydır, ancak çok daha fazla esneklik sağlayan programlı bir yaklaşım kullanılması tercih edilir.

Akıcı arayüzü kullanma örneği daha sonra verilir:

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

Akıcı arayüzün neden daha iyi olduğunu anlayamıyorum. Gerçekten mi? Benim bakış açımdan, veri ek açıklamaları daha açık ve daha net bir anlambilim hissine sahip gibi görünüyor.

Sorum şu: Akıcı bir arayüz neden özellikle bu durumda nitelikleri kullanmaktan daha iyi bir seçenek olsun?

(Not: Akıcı arayüzlerin tüm konsepti için oldukça yeniyim, bu yüzden lütfen bu konuda önceden bilgi beklemeyin.)

Referans: http://codefirst.codeplex.com/

Veri ek açıklamaları statiktir, örneğin bu yöntem bildirimi çalışma zamanında değişemez:

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

Akıcı arayüz dinamik olabilir:

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

kod bahsetmiyorum özellikleri arasında yeniden kullanılabilir.

Bu ifadenin geniş çapta uygulanması gerektiğini düşünmüyorum; Önce Kod'a çok özgüdür. İlk Kod'da veri ek açıklamaları, akıcı API'da bulunan işlevlerin yalnızca bir alt kümesini içerir. Başka bir deyişle, yalnızca akıcı API kullanılarak yapılabilen belirli model yapılandırmaları vardır.

Örneğin, ek açıklamalar kullanılarak belirtilemeyen bazı şeyler şunlardır:

• DateTime özelliğinin hassasiyeti
• Sayısal özelliklerin hassasiyeti ve ölçeği
• Sabit uzunluklu bir String veya Binary özelliği
• Unicode olmayan bir String özelliği
• İlişkilerin silindiğinde davranışı
• Gelişmiş haritalama stratejileri

Şahsen, MVC gibi diğer teknolojiler de bunlardan yararlanabileceğinden, mümkün olduğunca doğrulamayla ilgili veri ek açıklamalarını kullanma eğilimindeyim. Diğer her şey için akıcı API'yı tercih ederim.

Sorunuzun yanıtı bağlantıda verilmiştir.

Ardından alan adınız için geçerli olan kısıtlamalarınızı bu yöntemle programlı olarak tanımlarsınız.

Temel olarak, programsal yaklaşımın işletme üzerinde daha fazla kontrole sahip olduğu Nitelikler ile programlı yaklaşımın kullanılması az çok tercih edilir. Ancak, modelinizi süslemek için de bakabileceğiniz özel bir özellik eklemenin yolu vardır.

Bu yaklaşımı kullanırken tablolar ve sütunlar arasındaki ilişkileri bile tanımlayabilirsiniz. Sonuç olarak, alan adınız üzerinde daha fazla ince taneli kontrole sahip olmak istiyorsanız, EF4.1 ile birlikte gelen bu yeni yaklaşımı kullanabilirsiniz.

Bununla birlikte, yaygın doğrulama senaryoları için, Niteliklerin uygulanması, çoğu durumu kapsayacak şekilde sağlam olduğu için iyi çalışmalıdır; ayrıca size zaman kazandırabilir.

Benim düşüncem, ilişkilerin veritabanında nasıl oluşturulduğunu açıkladığınız için kod ilk uygulamaları için akıcı API'yi önermeleri. Veri ek açıklamaları kullanırsanız, Entity Framework tarafından oluşturulan veritabanı beklediğiniz gibi olmayabilir. İlk örneğiniz çok basit, bu yüzden sizin gibi veri açıklama yöntemini kullanacağım.