ส่วนต่อประสานที่คล่องแคล่วมีความยืดหยุ่นมากกว่าคุณสมบัติและทำไม?

ในการสอนโค้ด EF 4.1 รหัสแรกจะได้รับรหัสต่อไปนี้:

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

จากนั้นจะอธิบายว่าอินเทอร์เฟซที่คล่องแคล่วมีความยืดหยุ่นมากขึ้น:

คำอธิบายประกอบข้อมูลนั้นใช้งานง่ายอย่างแน่นอน แต่ควรใช้วิธีการเขียนโปรแกรมที่ให้ความยืดหยุ่นมากกว่า

ตัวอย่างของการใช้ส่วนต่อประสานที่คล่องแคล่วจะได้รับ:

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

ฉันไม่เข้าใจว่าทำไมอินเทอร์เฟซที่คล่องแคล่วดีกว่าที่คาดคะเน มันจริงเหรอ? จากมุมมองของฉันดูเหมือนว่าคำอธิบายประกอบข้อมูลจะชัดเจนยิ่งขึ้นและมีความรู้สึกที่ชัดเจนมากขึ้น

คำถามของฉันคือทำไมส่วนต่อประสานที่คล่องแคล่วจะเป็นตัวเลือกที่ดีกว่าการใช้แอตทริบิวต์โดยเฉพาะในกรณีนี้

(หมายเหตุ: ฉันค่อนข้างใหม่กับแนวคิดทั้งหมดของส่วนต่อประสานที่คล่องแคล่วดังนั้นโปรดคาดหวังว่าจะไม่มีความรู้ก่อนหน้านี้)

การอ้างอิง: http://codefirst.codeplex.com/

คำอธิบายประกอบข้อมูลเป็นแบบคงที่ตัวอย่างเช่นการประกาศวิธีนี้ไม่สามารถเปลี่ยนแปลงได้ในขณะใช้งานจริง:

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

อินเทอร์เฟซที่คล่องแคล่วสามารถเป็นแบบไดนามิก:

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

ไม่ต้องพูดถึงรหัสที่สามารถนำมาใช้ใหม่ระหว่างคุณสมบัติ

ฉันไม่คิดว่าควรใช้ข้อความอย่างกว้างขวาง มันเฉพาะเจาะจงกับ Code First มาก ใน Code First การเพิ่มความคิดเห็นของข้อมูลจะรวมเฉพาะส่วนย่อยของฟังก์ชันที่มีอยู่ใน API ที่คล่องแคล่ว กล่าวอีกนัยหนึ่งมีการกำหนดค่าแบบจำลองบางอย่างที่สามารถทำได้โดยใช้ API ได้อย่างคล่องแคล่วเท่านั้น

ตัวอย่างเช่นนี่คือบางสิ่งที่ไม่สามารถระบุได้โดยใช้คำอธิบายประกอบ:

• ความแม่นยำของคุณสมบัติ DateTime
• ความแม่นยำและขนาดของคุณสมบัติตัวเลข
• คุณสมบัติสตริงหรือไบนารีเป็นความยาวคงที่
• คุณสมบัติ String เป็น non-unicode
• พฤติกรรมการลบความสัมพันธ์
• กลยุทธ์การทำแผนที่ขั้นสูง

โดยส่วนตัวแล้วฉันมักจะใช้คำอธิบายประกอบที่เกี่ยวข้องกับการตรวจสอบข้อมูลทุกครั้งที่ทำได้เนื่องจากเทคโนโลยีอื่น ๆ เช่น MVC สามารถใช้ประโยชน์จากสิ่งเหล่านี้ได้ สำหรับทุกอย่างอื่นฉันชอบ API ที่คล่องแคล่ว

คำตอบสำหรับคำถามของคุณมีอยู่ในลิงค์

จากนั้นคุณกำหนดข้อ จำกัด ที่เกี่ยวข้องกับโดเมนของคุณภายในวิธีนี้โดยทางโปรแกรม

โดยทั่วไปจะมีการตั้งค่ามากกว่าหรือน้อยกว่าที่จะใช้ Attributes vs programmatic approach ซึ่งวิธีการเขียนโปรแกรมมีการควบคุมมากกว่าเอนทิตี อย่างไรก็ตามมีวิธีเพิ่มแอตทริบิวต์ในการตกแต่งแบบจำลองของคุณซึ่งคุณอาจมีลักษณะเช่นกัน

เมื่อใช้วิธีนี้คุณอาจอธิบายความสัมพันธ์ระหว่างตารางและคอลัมน์ ถ้าคุณเต็มใจที่จะควบคุมโดเมนของคุณอย่างละเอียดยิ่งขึ้นคุณสามารถใช้วิธีการใหม่นี้ที่มาพร้อมกับ EF4.1

อย่างไรก็ตามสำหรับสถานการณ์ทั่วไปของการตรวจสอบความถูกต้องของการใช้แอททริบิวต์ควรใช้งานได้ดีเพราะมีความทนทานในการครอบคลุมกรณีส่วนใหญ่ และนอกจากนี้มันอาจช่วยคุณประหยัดเวลา

ความคิดของฉันคือพวกเขาแนะนำ API ได้อย่างคล่องแคล่วสำหรับการติดตั้งโค้ดครั้งแรกเพราะคุณอธิบายอย่างชัดเจนถึงวิธีการสร้างความสัมพันธ์ในฐานข้อมูล หากคุณใช้คำอธิบายประกอบข้อมูลฐานข้อมูลที่สร้างโดย Entity Framework อาจไม่ใช่สิ่งที่คุณคาดหวัง ตัวอย่างเริ่มต้นของคุณนั้นง่ายมากดังนั้นเช่นคุณฉันจะใช้วิธีการเพิ่มความคิดเห็น