Là giao diện lưu loát linh hoạt hơn các thuộc tính và tại sao?

Trong mã EF 4.1 Hướng dẫn đầu tiên, đoạn mã sau được đưa ra:

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

Sau đó, nó được giải thích rằng giao diện trôi chảy linh hoạt hơn:

Chú thích dữ liệu chắc chắn dễ sử dụng nhưng tốt hơn là sử dụng phương pháp lập trình cung cấp sự linh hoạt hơn nhiều.

Ví dụ về việc sử dụng giao diện trôi chảy được đưa ra:

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

Tôi không thể hiểu tại sao giao diện trôi chảy được cho là tốt hơn. Có thật không? Từ quan điểm của tôi, có vẻ như các chú thích dữ liệu rõ ràng hơn và có nhiều cảm giác ngữ nghĩa rõ ràng với nó.

Câu hỏi của tôi là tại sao một giao diện trôi chảy sẽ là một lựa chọn tốt hơn so với việc sử dụng các thuộc tính, đặc biệt là trong trường hợp này?

(Lưu ý: Tôi còn khá mới đối với toàn bộ khái niệm về giao diện lưu loát, vì vậy vui lòng mong đợi không có kiến ​​thức trước về điều này.)

Tham khảo: http://codefirst.codeplex.com/

Chú thích dữ liệu là tĩnh, ví dụ khai báo phương thức này không thể thay đổi khi chạy:

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

Giao diện lưu loát có thể là động:

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

không đề cập đến mã có thể được sử dụng lại giữa các thuộc tính.

Tôi không nghĩ rằng tuyên bố đó nên được áp dụng rộng rãi; nó rất cụ thể đối với Code First. Trong Code First, chú thích dữ liệu chỉ bao gồm một tập hợp con của chức năng có sẵn trong API thông thạo. Nói cách khác, có một số cấu hình mô hình nhất định chỉ có thể được thực hiện bằng API thông thạo.

Ví dụ: đây là một số điều không thể chỉ định bằng cách sử dụng các chú thích:

• Độ chính xác của thuộc tính DateTime
• Độ chính xác và tỷ lệ của các thuộc tính số
• Thuộc tính Chuỗi hoặc Nhị phân có độ dài cố định
• Một thuộc tính String là không unicode
• Hành vi xóa các mối quan hệ
• Chiến lược lập bản đồ nâng cao

Cá nhân, tôi có xu hướng sử dụng các chú thích dữ liệu liên quan đến xác nhận bất cứ khi nào có thể vì các công nghệ khác như MVC cũng có thể tận dụng lợi thế của chúng. Đối với mọi thứ khác, tôi thích API thông thạo hơn.

Trả lời câu hỏi của bạn được cung cấp trong liên kết.

Sau đó, bạn xác định các ràng buộc áp dụng cho tên miền của mình trong phương pháp này theo chương trình.

Về cơ bản, ít nhiều ưu tiên sử dụng các thuộc tính so với phương pháp lập trình, trong đó phương pháp lập trình có nhiều quyền kiểm soát hơn đối với thực thể. Tuy nhiên, có một cách tùy chỉnh thêm Thuộc tính để trang trí mô hình của bạn mà bạn có thể trông giống như vậy.

Khi sử dụng phương pháp này, bạn thậm chí có thể mô tả mối quan hệ giữa các bảng và cột. Tóm lại, nếu bạn sẵn sàng kiểm soát chi tiết hơn đối với tên miền của mình, bạn có thể sử dụng phương pháp mới này đi kèm với EF4.1.

Tuy nhiên, đối với các kịch bản phổ biến về xác nhận áp dụng Thuộc tính sẽ hoạt động tốt vì nó mạnh mẽ để bao quát hầu hết các trường hợp; và ngoài ra nó có thể giúp bạn tiết kiệm thời gian.

Tôi nghĩ rằng họ đề xuất API thông thạo cho việc triển khai mã trước vì bạn mô tả rõ ràng cách các mối quan hệ được tạo trong cơ sở dữ liệu. Nếu bạn sử dụng chú thích dữ liệu, cơ sở dữ liệu được tạo bởi Entity Framework có thể không như bạn mong đợi. Ví dụ ban đầu của bạn rất đơn giản, vì vậy, giống như bạn, tôi sẽ chỉ sử dụng phương pháp chú thích dữ liệu.