유창한 인터페이스가 속성보다 융통성이 있으며 그 이유는 무엇입니까?

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 속성의 정밀도
• 숫자 속성의 정밀도 및 스케일
• 고정 길이의 문자열 또는 이진 속성
• 비 유니 코드로서의 문자열 속성
• 관계의 삭제시 동작
• 고급 매핑 전략

개인적으로 MVC와 같은 다른 기술도 이러한 이점을 활용할 수 있기 때문에 가능하면 유효성 검사 관련 데이터 주석을 사용하는 경향이 있습니다. 다른 모든 것에는 유창한 API를 선호합니다.

귀하의 질문에 대한 답변이 링크에 제공됩니다.

그런 다음이 방법 내에서 도메인에 적용 할 수있는 제약 조건을 프로그래밍 방식으로 정의하십시오.

기본적으로 프로그래밍 방식이 엔터티를 더 많이 제어하는 ​​경우 특성 대 프로그래밍 방식을 사용하는 것이 다소 선호됩니다. 그러나 모델을 장식하기 위해 속성을 추가하는 사용자 정의 방법이 있습니다.

이 방법을 사용할 때 테이블과 열 사이의 관계를 설명 할 수도 있습니다. 결론적으로, 도메인을보다 세밀하게 제어하려는 경우 EF4.1과 함께 제공되는이 새로운 접근 방식을 사용할 수 있습니다.

그러나 일반적인 유효성 검사 시나리오의 경우 대부분의 경우를 다루는 것이 강력하기 때문에 속성을 적용하면 제대로 작동합니다. 또한 시간을 절약 할 수 있습니다.

내 생각은 데이터베이스에서 관계가 생성되는 방법을 명시 적으로 설명하기 때문에 코드 첫 번째 구현에 유창한 API를 권장하는 것입니다. 데이터 주석을 사용하는 경우 Entity Framework에서 생성 한 데이터베이스가 예상과 다를 수 있습니다. 초기 예제는 매우 간단하므로 데이터 주석 방법을 사용합니다.