IT박스

Entity Framework 코드 우선-Fluent Api 대 데이터 주석의 장단점

itboxs 2020. 8. 10. 07:51
반응형

Entity Framework 코드 우선-Fluent Api 대 데이터 주석의 장단점


Entity Framework 코드 우선을 사용하여 데이터베이스를 만들 때 코드에서 많은 데이터베이스 모델을 추출 할 수 있습니다. Fluent API 및 / 또는 속성을 사용하여 모델을 미세 조정할 수 있습니다.

데이터 주석과 비교하여 Fluent Api의 장점과 단점은 무엇입니까? 즉, 특정 상황에서 두 방법을 모두 사용할 수 있다고해도 어떤 경우에 한 방법이 다른 방법보다 우선해야합니까?


DataAnnotations로 구성 할 수있는 모든 것은 Fluent API에서도 가능합니다. 그 반대는 사실이 아닙니다. 따라서 구성 옵션과 유연성의 관점에서 Fluent API가 "더 우수"합니다.

Fluent API에서는 가능하지만 DataAnnotations로는 불가능한 구성 예제 (전체 목록은 아님) (내가 볼 수있는 한) :

  • 계단식 삭제 끄기 :

    .WillCascadeOnDelete(false)

  • 키가 개체 모델에 노출되지 않은 경우 데이터베이스에 외래 키 열 이름을 지정합니다.

    .Map(conf => conf.MapKey("MyForeignKeyID"))

  • 특히 개체 모델에서 연결의 한 쪽만 노출되는 모든 경우에 관계를 세부적으로 조정합니다.

    .WithMany(...), WithOptional(...), WithRequiredDependent(...),WithRequiredPrincipal(...)

  • 개체 모델과 데이터베이스 테이블 간의 상속 매핑 사양 (Table-Per-Hierarchy, Table-Per-Type, Table-Per-Concrete-Class) :

    .Map<TDerived>(Action<EntityMappingConfiguration<TDerived>> ...)

편집 : Microsoft는 Fluent API를 "고급 기능"으로 간주합니다 ( 여기 에서 인용 ).

Fluent API는 더 고급 기능으로 간주되며, 요구 사항에서 Fluent API를 사용해야하는 경우가 아니면 데이터 주석을 사용하는 것이 좋습니다.

그러나 제 생각에는 DataAnnotations의 한계에 매우 빠르게 도달합니다 (아마도 매우 간단한 개체 모델 제외). 더 이상 DataAnnotations로 모델을 미세 조정할 수없는 경우 마지막 수단은 기본 매핑 규칙을 따르는 것입니다 (해당 규칙에 따라 속성 이름 지정). 현재는 규칙을 덮어 쓸 수 없습니다 (비활성화 만 가능합니다. MS는 향후 EF 릴리스에서 규칙에 대한 구성 옵션을 제공한다고 발표했습니다). 그러나 객체 모델을 정의 할 때 매핑 규칙에 의해 강제되는 것을 원하지 않는 경우 유일한 옵션은 Fluent API입니다.

Fluent API를 배우는 것은 거의 필수입니다. DataAnnotations는 간단한 응용 프로그램에 적합합니다.

참고 URL : https://stackoverflow.com/questions/5354900/entity-framework-code-first-advantages-and-disadvantages-of-fluent-api-vs-data

반응형