저는 최근에 무지하고 시간 부족으로 여러 프로젝트의 도메인 모델 (POCO 엔티티 클래스)을 하나의 'DataModel'프로젝트로 병합했습니다. 모든 프로젝트에서 전용 DbContext를 복제하십시오. DbContext 확장과 같이 다양한 클라이언트 프로젝트에서 DbSet 인스턴스를 추가 할 수있는 일반적인 기능을 수행한다는 것이 이상적이라고 생각합니다.많은 도메인 모델이 EF 5에서 하나의 데이터 컨텍스트를 공유합니다.
DbSet 클래스가 저장소 기능을 완벽하게 충족한다고 주장하는 저자와 동일한 서클에서 일반적으로 동의의 말씀을 읽었습니다.
누구나 다른 프로젝트가 공유 DbContext에 등록 된 도메인 모델 (도메인 엔터티 집합)을 모두 가질 수있는 한 프로젝트에있을 수있는 일반 DbContext를 작성하는 데 조언을 제공 할 수 있습니까? 자신의 저장소로 행동 할 것인가?
재미있는 아이디어를 등록 된 다른 프로젝트 모두가 자신의 도메인 모델 (도메인 개체의 집합을) 할 수 있습니다 하나 개의 프로젝트에 존재할 수있는 일반적인 DbContext를 구축,하지만 난 모르겠어요 무엇을 그것으로 얻을 것입니다.
하나만 들어, 당신은 단순히 db.Customer (또는 이와 유사한)을 입력 할 수 없을 것입니다. 항상 genericdb.Set<Customer>(), 을 모르는 경우genericdb이 약 Customer인지 전혀 모르는 상태 여야합니다. 등록되지 않았을 수 있습니다.
그런 다음 어떻게 등록해야합니까?
DbContext 유도 된 클래스의 DbSet 속성을 생성 등 테이블과 열 이름에 관한 코드 첫 번째 기본 규칙, 복수화에 의존 : 컨텍스트는 데이터베이스 모델에 클래스를 매핑 할 수 있도록하는 방법에는 두 가지가 있습니다EntityTypeConfiguration<T>의 각 클래스를 제공하여 도메인 클래스를 등록해야 할 것이다, 그래서첫 번째 옵션은 일반적인 문맥 클래스의 목적을 패배. (이것은 컨텍스트의 생성자에서 그런 방식으로 수행되어야합니다.)
더 암시되는 점은 어떤 클래스 그룹이 함께 속하고 일관된 목록을 제공 할 수 있는지를 알고있는 구성 요소/서비스가 필요하다는 것입니다 구성 중. 따라서, 조직화 된 컨텍스트를 컨텍스트 전용으로 사용하는 대신 자신 만의 구성도를 만들어야합니다.
하지만 다시 시작하십시오. 프로젝트에 이전에 존재했던 컨텍스트를 제공하는 DbContext 팩토리를 포함하는 DAL을 만들 수 없었습니까? 이런 식으로 전용 DbContext 클래스를 복제 할 필요가 없습니다.