2014-07-11 2 views
3

배포 후에도 많은 데이터베이스 변경이 발생할 것으로 예상되는 ASP.NET Web Forms 프로젝트에서 작업하고 있습니다.배포 후 데이터베이스 변경에 대한 엔터티 프레임 워크를 사용하는 최상의 방법

우리의 선호는 Entity Framework 5와 Database First 디자인 패러다임을 사용하는 것이 었습니다. 그러나 배포 후에도 데이터베이스를 많이 변경해야하므로 데이터베이스를 먼저 사용하면 데이터베이스를 업데이트 할 때마다 전체 모델을 삭제하고 다시 생성해야합니다. 이 과정을 덜 고통스럽게 만드는 모범 사례가 있습니까?

+1

@DavinTryon 데이터베이스 우선 디자인 패러다임을 사용하고 있으므로 마이그레이션을 사용할 수 없습니다. – Shuaib

+0

DB 사용하기 먼저 문제를 해결하기 위해 아무 것도 할 수 없습니다. 그러나 DB를 코드 첫 번째로 리버스 엔지니어링하고 마이 그 레이션을 사용하는 것을 멈출 수있는 방법은 없습니다. 예를 들어, 리버스 엔지니어링을 수행하기 위해 Entity Framework Power Tools (현재 베타 4 버전이지만 잘 작동 함)를 사용할 수 있습니다. – JotaBe

+0

대체 옵션을 제공하기 위해 내 대답을 업데이트했지만 마이그레이션을 사용하는 것이 훨씬 더 좋습니다. 나는 왜 내 업데이트 된 대답에 설명합니다. – JotaBe

답변

7

마이그레이션을 사용할 수 있도록 코드 우선을 사용해야합니다.

더 구체적으로는 수동 마이그레이션을 사용합니다.

수동 마이그레이션을 사용하면 언제든지 마이그레이션을 만들 수 있습니다. 마이그레이션은 다음과 같은 정보를 가지고 :

  • 현재 모델
  • "지침"의 집합은 이전 마이그레이션
  • 으로 다운 그레이드 할 수
  • 이전 마이그레이션에서 업그레이드 "지침"의 세트의 스냅 샷

필요한 마이그레이션 외에도 앱을 배포 할 때 새로운 마이그레이션을 추가해야합니다. 예를 들어 앱 버전 1.0을 배포 할 때 '버전 1.0'이라는 이전을 만들 수 있습니다.

새로운 안정 버전을 마칠 때마다 단순히 "버전 1.1"또는 "버전 1.2"와 같은 새 마이그레이션을 추가하기 만하면됩니다.

배포 된 응용 프로그램 버전이 있고 새 버전으로 업그레이드 (또는 다운 그레이드)해야 할 때 흥미로운 부분이 나타납니다.

DB를 하나의 특정 버전 에서 다른 특정 버전으로 업그레이드 (또는 다운 그레이드) 할 수있는 명령이 있습니다. DB에 대한 연결을 직접 지정하거나 DB에 변경 사항을 적용 할 SQL 스크립트를 작성할 수 있습니다. 당신이 고객 서버의 버전 1.0을 배포하고 버전 1.2 소프트웨어를 업그레이드해야하는 경우 예를 들어,이 작업을 수행 할 수 있습니다

Update-Database -SourceMigration "Version 1.0" -TargetMigration "Version 1.2" 
     -Script 

이는 DB에서 실행할 수있는 SQL 스크립트를 생성합니다 버전 1.0에서 1.2로 업그레이드 할 수 있습니다.

당신이 단순히 입력 명령어 마이그레이션의에 대한 도움이 필요한 경우 :

get-help Update-Database -full 

(Update-Database 명령 이름을 지정할 수있는 다른 같은 Add-Migration)

그것은 당신이 필요 가능성이 있습니다 모델이있는 프로젝트, 연결 문자열 이름, .config 파일이있는 프로젝트 이름 또는 지정된 매개 변수 및 솔루션의 프로젝트 구조에 따라 다른 것을 지정하십시오.

마이그레이션에 대한 자세한 내용은 MSDN EF Code First Migration을 참조하십시오.

참고 추가 된 내용 : 응용 프로그램을 실행할 때 최신 버전으로 자동으로 마이그레이션 할 수있는 새 DB 초기화 프로그램이 있습니다.저는 실제 응용 프로그램에서 작업했으며, 매력처럼 작동합니다.

대안 SSDT

당신이 조언을 따라하지 않으려면, 당신은 버전 당신에 따라 한 independente 응용 프로그램으로 SQL Server 데이터 VS 내부에 설치할 수있는 도구 (또는 작업을 사용할 수 있습니다 사용).

이 도구의 아이디어는 프로젝트 (DB 스키마 스냅 샷)와 기존 DB를 비교하고 프로젝트의 스키마와 일치하도록 DB를 변경하는 스크립트를 생성 할 수 있다는 것입니다. (실제로 프로젝트와 DB의 어떤 조합도 비교할 수 있습니다)

프로젝트의 버전을 CVS에 보관하면 프로젝트의 한 버전에서 다른 버전의 프로젝트로 변경 사항을 확인할 수도 있습니다.

참고 사항 : SSDT 프로젝트는 스키마의 모든 개체를 포함하여 전체 DB를 구축 할 수있는 스크립트 집합입니다. 기존 DB 또는 viceversa에서 생성 할 수 있습니다. 그런 다음 데이터베이스 또는 SSDT 프로젝트의 조합을 소스 또는 대상으로 계속 비교할 수 있으며 변경 사항이있는 특정 개체를 변경하기 위해 스크립트를 적용해야합니다. (원본은 소스처럼 보이도록 대상을 변경하기 위해 생성되지만 소스와 대상을 쉽게 바꿀 수 있습니다.)

이 방법은 대안이지만 마이그레이션을 사용자 지정할 수 있으므로 훨씬 더 강력합니다. 생성시 "마스터 테이블"채우기, 새 열의 초기 값 설정, 등등. SSTD를 사용한다면 모든 것을 손으로해야하며주의 깊게 추적해야합니다. 따라서 마이그레이션을 사용하는 것이 좋습니다.

+0

고마워요 ....하지만 이런 식으로 마이그레이션을 사용하면 ... 코드 첫 번째 모델을 변경할 때마다 전체 응용 프로그램을 다시 게시해야합니다. 이게 고통스럽지 않은가? – Shuaib

+0

개발 중에 모델을 변경할 때마다'Add_Migration "Name"과'Update-Database' (일반적으로 매개 변수없이)를 실행하면 모델과 DB가 동기화됩니다. 그렇게 고통스럽지 않습니다. 당신이 그것을 잊어 버리면, 당신은 당신이 그것을 잊어 버린 (excepcion는 모델과 db가 일치하지 않는다고 말하는) 예외를 실행하면 응용 프로그램을 실행할 때 예외를 얻을 것이다. 이 작업과 "DB + 업데이트 모델 변경"또는 "모델 변경 + DB 업데이트"사이에는 큰 차이가 없다고 생각합니다. 나는 사람들이 그것을 시도하지 않았기 때문에 이주를 두려워한다고 생각한다. 그들은 문제보다 많은 이점을 가져옵니다. – JotaBe

+0

나는 마이 그 레이션 및 DB 동기화에 대해 걱정하지 않는다 ... 나는 당신이 코드를 처음 모델에서 작은 것들을 바꿀 때마다 ** C# 코드 **를 다시 컴파일하고 다시 게시하는 것에 대해 걱정이된다. – Shuaib