EF6에서 EF Core로 포트 - 데이터베이스를 원본으로

데이터베이스를 원본으로 사용하는 경우 업그레이드에는 주로 생성된 엔터티의 모양에 대한 변경 내용을 처리하는 작업이 포함됩니다. 마이그레이션 단계는 다음과 같습니다.

1. 특정 시점을 선택하여 데이터베이스를 모델링합니다.
2. EF6 프로젝트가 최신 상태이고 데이터베이스와 동기화되어 있는지 확인합니다.
3. EF Core 프로젝트를 만듭니다.
4. 스캐폴딩 도구를 사용하여 데이터베이스를 코드로 리버스 엔지니어링합니다.
5. EF Core에서 생성된 클래스가 코드와 호환되는지 확인합니다.
6. 예외의 경우 생성된 클래스를 수정하고 모델 구성을 업데이트하거나 코드를 모델에 맞게 조정합니다.

EF Core는 현재 데이터베이스 복사본을 성공적으로 생성하는 데 필요한 모든 항목을 스캐폴드하지만 데이터베이스 우선 접근 방식에는 대부분의 코드가 필요하지 않습니다. 이에 대한 수정 사항은 문제 #10890에서 추적됩니다. 시퀀스, 제약 조건 이름, 고유하지 않은 인덱스 및 인덱스 필터 등 필요하지 않은 경우 안전하게 무시할 수 있습니다.

스키마 변경 처리

데이터베이스가 진실의 원본인 경우 EF Core는 마이그레이션을 통해 푸시하는 대신 데이터베이스에서 스키마 정보를 가져옵니다. 일반적인 워크플로는 데이터베이스 스키마가 변경 될 때마다 리버스 엔지니어링 단계를 다시 실행하는 것입니다. 포괄적인 테스트 도구 모음은 스캐폴딩 프로세스를 자동화하고 테스트를 실행하여 변경 내용을 확인할 수 있기 때문에 이 접근 방식에 유용합니다.

모델 차이점을 처리하기 위한 팁

다양한 이유로 C# 도메인 모델을 리버스 엔지니어링에서 생성된 모델과 다르게 셰이핑할 수 있습니다. 대부분의 경우 이는 스키마가 변경될 때마다 자동으로 생성되는 코드를 수동으로 업데이트하는 것을 의미합니다. 코드가 다시 생성될 때 추가 작업을 방지하는 한 가지 방법은 DbContext 및 관련 엔터티에 부분 클래스를 사용하는 것입니다. 그런 다음 덮어쓰지 않는 별도의 클래스 파일 집합에서 데이터베이스에서 추적되지 않는 비즈니스 논리 및 속성과 관련된 코드를 유지할 수 있습니다.

모델이 생성된 모델과 크게 다르지만 자주 변경되지 않는 경우 고려해야 할 한 가지 옵션은 리포지토리 패턴을 어댑터로 사용하는 것입니다. 리포지토리는 EF Core에서 생성된 클래스를 사용하고 사용하는 사용자 지정 클래스를 게시할 수 있습니다. 이렇게 하면 스키마가 변경될 때마다 애플리케이션 전체 리팩터링을 수행하지 않고 리포지토리 코드로 격리하여 변경 내용의 영향을 줄일 수 있습니다.

대체 워크플로를 고려하고 하이브리드 접근 방식과 유사한 단계를 수행할 수 있습니다. 매번 새 클래스 집합을 생성하는 대신 새 클래스만 생성하도록 특정 테이블을 나타냅니다. 기존 클래스를 "있는 그대로" 유지하고 변경된 속성을 직접 추가하거나 제거합니다. 그런 다음, 데이터베이스가 기존 클래스에 매핑되는 방식의 변경 내용을 해결하도록 모델 구성을 업데이트합니다.

코드 생성 사용자 지정

EF Core 6은 현재 생성된 코드의 사용자 지정을 지원하지 않습니다. 사용할 수 있는 EF Core Power Tools와 같은 타사 솔루션이 있습니다. 추천 커뮤니티 도구 및 확장 목록은 EF Core 도구 및 확장을 참조하세요.

마지막으로, EF6와 EF Core 간의 차이점에 대한 자세한 목록을 검토하여 포팅과 관련된 나머지 문제를 해결합니다.