2014-04-08 3 views
2

CMS 테이블의 엔티티 (예 : Users 테이블)와 함께 CmsDbContext라는 상위 DbContext가있는 확장 가능한 사용자 지정 CMS 솔루션을 구축하고 있습니다. CmsDbContext는 자동 마이그레이션을 사용하도록 설정합니다. DbSet 속성과 사용자 지정 POCO를 추가/매핑하여 사용자 지정 추가 테이블/엔터티를 만들려면 최종 사용자가 CmsDbContext에서 상속하도록 허용하십시오.동일한 데이터베이스 내의 기본 DbContexts에서 여러 마이 그 레이션 및 상속이있는 Entity Framework

Cms는 파생 된 DbContext를 초기화하기 전에 CmsDbContext를 PreStart에서 초기화해야합니다. CmsDbContext를 초기화하면 테이블이 성공적으로 만들어집니다. 파생 된 DbContext를 초기화 할 때 CustomCmsDbContext를 사용하면 추가 테이블이 성공적으로 만들어집니다. 그러나 웹 응용 프로그램이 다시 시작되면 CmsDbContext의 마이그레이션 프로세스가 컨텍스트에서 소유하지 않은 테이블을 지우고 상속 된 CustomDbContext의 테이블이 다시 만들어집니다.

DbMigrationsConfiguration will의 ContextKey 속성 때문에 같은 데이터베이스 내에서 자동 마이그레이션이 가능한 여러 개의 관련되지 않은 DbContext를 만들 수 있음을 알고 있습니다. 그러나 CustomCmsDbContext 컨텍스트가 CmsDbContext로 매핑 된 기존 테이블에 대해 쿼리를 수행 할 수 있도록하기 위해 여기에 상속이 필요하므로 두 컨텍스트 모두 마이그레이션을 사용할 수있는 하나의 DbContext처럼 동작합니다.

부모 DbContext가 마이그레이션 프로세스 중에 자식 DbContext의 테이블을 삭제하고 마이그레이션 프로세스 중에 자식 DbContext가 누락 된 테이블을 다시 만드는 문제가 있다는 것을 알고 있습니다.

DbContext가 소유하고 있지 않은 테이블을 마이그레이션하는 것을 방지하려면 어떻게해야합니까? 컨텍스트에 대한 고객의 추가/편집 사용자 definied 열 또는 테이블을 보자 :

public class CmsDbContext: DbContext { 

    static CmdDbContext() { 
     Database.SetInitializer(new MigrateDatabaseToLatestVersion<CmsDbContext, Migrations.CmsDbContextConfiguration>()); 
    } 

    public DbSet<User> Users { get; set; } 
} 


public class CustomCmdDbContext: CmsDbContext { 

    static CustomCmdDbContext() { 
     Database.SetInitializer(new MigrateDatabaseToLatestVersion<CustomCmdDbContext, Migrations.CustomCmdDbContext>()); 
    } 
    public DbSet<CustomEntity> CustomEntities { get; set; } 
} 
+0

EF 마이그레이션이 이러한 방식으로 작동하도록 설계되지 않았 음을 가장 잘 알고 있습니다. 나는 다른 말을 듣고 싶지만 의심 스럽습니다. –

+0

취할 수있는 접근 방법은 두 부분으로 나누어 생각할 수 있습니다. (1) 데이터베이스와 상호 작용하는 방법과 (2) 마이그레이션하는 방법, 데이터베이스 스키마/데이터를 시간 경과에 따라 고려해야합니다. 여러 데이터 컨텍스트가 동일한 데이터베이스 테이블과 상호 작용하는 것은 좋지만, 테이블을 공유하는 여러 마이그레이션에서 EF가 발생하는 것을 발견했습니다. 내가하는 일은 여러 인터페이스를 구현할 수있는 단일 "MigrationsDbContext"를 만든 다음 해당 인터페이스를 구현하는 데 필요한만큼의 데이터 db 컨텍스트를 만드는 것입니다. 나는 이것이 당신이 원하는 모듈 형 시스템이 아니라고 확신한다 ... 나는 단지 당신이 원하는 것을 생각하지 않는다. –

+0

인터페이스의 아이디어는 문제를 해결할 수 있지만 문제는 최종 "사용자"(프로그래머)는 Cms 코드를 변경하지 않고 대신 별도의 라이브러리에 새 코드를 작성하여 Cms를 플러그인으로 확장하므로 기본 코어가 코드를 알지 못합니다. –

답변

3

This blog post from Rowan Miller이 매우 유사한 시나리오를 descripes : 여기

는 의사 코드입니다.

+0

아주 좋은 블로그 글. 나는 곧 그것을 밖으로 검사하고 저 포스트에서 무언가가 나의 필요로 적합하다는 것을 볼 것이다. 공유해 주셔서 감사합니다. –