Entity Framework 6 데이터베이스 우선 및 양파 아키텍처

Question

먼저 Entity Framework 6 데이터베이스를 사용하고 있습니다. 나는 양파 건축을 구현하기 위해 프로젝트를 전환하여 우려를 더 잘 분리하는 방향으로 나아 간다. 많은 기사를 읽었으며 많은 비디오를 보았지만 솔루션 구조를 결정할 때 몇 가지 문제가있었습니다.

4 가지 프로젝트가 있습니다. 코어, 인프라, 웹 & 테스트.

내가 배운 것을 보면 .edmx 파일을 "인프라"폴더 아래에 배치해야합니다. 그러나 Repository와 Unit of Work 패턴을 사용하여 EF 디커플링과 Dependency Injection을 지원하는 방법에 대해서도 읽었습니다. 이 존재와

는 말했다 :

• 내가 내 모델의 모든 개체에 대한 CORE에서 저장소 인터페이스를 작성해야합니까? 그렇다면 거대한 데이터베이스에서 어떻게 이것을 유지할 수 있습니까? automapper를 살펴 봤지만 IEnumererables 대 IQueryables를 제시하는 문제가 발견되었지만 사용할 수있는 확장 프로그램이 있습니다. 이 경로를 더 깊이 시도 할 수는 있지만 처음부터 다시 듣고 싶습니다.

• 대신 인프라에서 edmx를 그대로두고 엔터티의 .tt T4 파일을 CORE로 이동해야합니까? 이것은 단단한 커플 링 또는 좋은 해결책을 제시합니까?

• 제네릭 리포지토리 인터페이스는 귀하가 제공 한 제안과 잘 작동합니까? 또는 EF6가 이미 저장소 및 UoW 패턴 문제를 해결 했습니까?

제 질문을보고 주시고 다른 대안도 제시해주십시오.

내가 발견 대답하지 않은 여기에 유사한 게시물 : 당신은 그들이 그들에 대한 참조를 볼 경우, 그래서 EF6 and Onion architecture - database first and without Repository pattern

Answer 1

데이터베이스가 먼저 완전히 포트 및 어댑터 또는 육각형 구조 일명 양파 아키텍처 (배제하지 않습니다, 같은 일),하지만 그것은 확실히 더 어렵습니다. 어니언 아키텍처와 우려 사항을 분리하면 도메인 중심 디자인과 매우 잘 어울립니다. (이미 some of my videos on this subject on Pluralsight으로 여겨지는 트위터에 대해 언급 한 것 같습니다.)

코어 또는 웹 프로젝트에 EDMX를 두지 마십시오. 인프라가 적합한 위치입니다. 이 시점에서 데이터베이스를 먼저 사용하면 Infrastructure에 EF 엔터티를 갖게됩니다. 하지만 비즈니스 개체/도메인 엔터티를 Core에 저장하려고합니다. 이 시점에서이 경로를 계속 사용하려면 기본적으로 두 가지 옵션이 있습니다.

1) 코어에서 POCO 엔터티를 가질 수 있도록 데이터베이스에서 코드 (도구 사용)를 먼저 전환하십시오.

2) 인프라 엔터티와 핵심 개체간에 앞뒤로 맵핑 할 수 있습니다 (예 : AutoMapper 등). EF가 POCO 엔티티를 지원하기 전에, 필자가 사용했을 때의 접근 방법이었습니다. 핵심 오브젝트 만 다루지 만 내부적으로는 EF 특정 엔티티에 매핑하는 리파지토리를 작성했습니다.

저장소 및 작업 단위에 관한 질문에 대해서는 이미 SO 및 다른 곳에서 많은 내용이 있습니다. 확실히 일반적인 저장소 구현을 사용하여 대규모 엔티티 집합에 대한 CRUD 액세스를 쉽게 할 수 있으며 시나리오에서 빠르게 이동할 수있는 것처럼 들릴 수 있습니다.그러나 일반적인 권장 사항은 비즈니스 개체에 액세스하는 일반적인 방법으로 일반 저장소를 사용하지 않고 집계 (집계 루트 당 하나의 구체적인 리포지토리가있는 DDD 또는 내 DDD 코스 (Pluralsight의 Julie Lerman 참조) 참조)를 사용하는 것입니다. CRUD 작업에서 복잡한 비즈니스 엔티티도 분리 할 수 ​​있으며, 정당한 Aggregate 접근법을 따릅니다. 이 접근법의 이점은 객체 액세스 방법을 제한하고 대규모 (대규모) 데이터베이스 엔티티 집합에 대해 Facade에 유사한 이점을주는 것입니다.

응용 프로그램 당 하나의 dbcontext 만있을 수 있다고 생각하지 마십시오. 친환경 필드 어플리케이션으로 시작하지 않고 시간이 지남에 따라이 디자인을 발전시키는 것 같습니다. 이를 위해 .edmx 파일과 CRUD 목적을위한 일반적인 저장소를 유지할 수 있지만 POCO 엔티티, 관심사 분리, 테스트 가능성 향상 등을 보증하는 특정 작업 집합에 대해 새로운 코드 첫 번째 dbcontext를 만듭니다. 시간이 지남에 따라 기존의 dbcontext를 그대로 유지하면서 잃어 버리지 않고 현재의 기능을 유지하면서 필요한 코드를 대량으로 옮길 수 있습니다.

Answer 2

DDD 프로젝트에서 엔티티 프레임 워크 6.1을 사용하고 있습니다. 어니언 아키텍처를 원한다면 먼저 코드가 잘 작동합니다.

내 프로젝트에서는 도메인 모델에서 저장소를 완전히 격리했습니다. 응용 프로그램 서비스는 저장소를 사용하여 데이터베이스에서 집계를로드하고 집계를 데이터베이스에 유지합니다. 따라서 도메인 (핵심)에는 저장소 인터페이스가 없습니다.

T4를 사용하여 별도의 어셈블리에서 POCO를 생성하는 두 번째 옵션은 좋은 아이디어입니다. 도메인 모델 (핵심)은 지속성을 모르는 것이어야 함을 기억하십시오.

일반 저장소는 집계 수준 작업을 수행하는 데 적합하지만 모든 집계가 모두 generic repository operations을 필요로하지 않기 때문에 특정 저장소를 사용하는 것이 더 좋습니다.

http://codingcraft.wordpress.com/