코드 우선 대 모델 / 데이터베이스 우선 [닫힘]

EDMX 다이어그램과 함께 Entity Framework 4.1 Code-first over Model / Database-first를 사용할 때의 장단점은 무엇입니까?

EF 4.1을 사용하여 데이터 액세스 계층을 구축하는 모든 접근 방식을 완전히 이해하려고합니다. 리포지토리 패턴 및을 사용하고 IoC있습니다.

코드 우선 접근 방식을 사용할 수 있다는 것을 알고 있습니다. 엔티티와 컨텍스트를 직접 정의 ModelBuilder하고 스키마를 미세 조정하는 데 사용하십시오.

또한 EDMX다이어그램 을 만들고 T4 템플릿을 사용하여 동일한 POCO클래스 를 생성하는 코드 생성 단계를 선택할 수 있습니다.

두 경우 모두 나는 무의미하고 맥락에서 파생되는 POCO객체로 끝납니다 .ORMDbContext

Enterprise Manager에서 데이터베이스를 디자인하고 모델을 신속하게 동기화하고 디자이너를 사용하여 데이터베이스를 미세 조정할 수 있으므로 데이터베이스 우선이 가장 매력적입니다.

그렇다면이 두 접근법의 차이점은 무엇입니까? VS2010과 Enterprise Manager의 기본 설정에 관한 것입니까?

차이점은 다음과 같습니다.

먼저 코드

• 하드 코어 프로그래머는 어떤 종류의 디자이너도 좋아하지 않으며 EDMX xml에서 매핑을 정의하는 것이 너무 복잡하기 때문에 매우 인기가 있습니다.
• 코드에 대한 모든 권한 (수정하기 어려운 자동 생성 코드 없음).
• 일반적인 기대는 DB를 귀찮게하지 않는 것입니다. DB는 논리가없는 스토리지 일뿐입니다. EF는 창조를 처리 할 것이며 당신은 그것이 어떻게 작동하는지 알고 싶지 않습니다.
• 코드가 데이터베이스를 정의하기 때문에 데이터베이스에 대한 수동 변경 내용이 손실 될 수 있습니다.

먼저 데이터베이스

• DBA가 설계 한 DB가 있거나 별도로 개발되었거나 기존 DB가있는 경우 매우 인기가 있습니다.
• EF에서 엔티티를 작성하게하고 맵핑 수정 후 POCO 엔티티를 생성합니다.
• POCO 엔터티에 추가 기능이 필요한 경우 템플릿을 수정하거나 부분 클래스를 사용해야합니다.
• 데이터베이스가 도메인 모델을 정의하므로 데이터베이스를 수동으로 변경할 수 있습니다. 항상 데이터베이스에서 모델을 업데이트 할 수 있습니다 (이 기능은 매우 효과적입니다).
• 나는 종종 이것을 VS 데이터베이스 프로젝트 (Premium 및 Ultimate 버전 만)와 함께 사용합니다.

먼저 모델

• 디자이너 팬이라면 인기가 있습니다 (= 코드 나 SQL 작성이 마음에 들지 않습니다).
• 모델을 "그리기"하고 워크 플로가 데이터베이스 스크립트를 생성하고 T4 템플릿이 POCO 엔터티를 생성하게합니다. 당신은 당신의 엔티티와 데이터베이스에 대한 제어의 일부를 잃을 것이지만 작은 쉬운 프로젝트의 경우 매우 생산적입니다.
• POCO 엔터티에 추가 기능이 필요한 경우 템플릿을 수정하거나 부분 클래스를 사용해야합니다.
• 모델이 데이터베이스를 정의하기 때문에 데이터베이스에 대한 수동 변경 사항이 손실 될 수 있습니다. 데이터베이스 생성 파워 팩이 설치되어있는 경우 더 잘 작동합니다. VS에서 데이터베이스 프로젝트를 업데이트하거나 (생성하는 대신) 업데이트하거나 데이터베이스 프로젝트를 업데이트 할 수 있습니다.

EF 4.1의 경우 먼저 Code First와 Model / Database와 관련된 몇 가지 다른 기능이있을 것으로 기대합니다. Code에서 먼저 사용되는 Fluent API는 EDMX의 모든 기능을 제공하지 않습니다. 저장 프로 시저 매핑, 쿼리 뷰, 뷰 정의 등과 같은 기능은 Model / Database를 먼저 사용할 때 작동 DbContext하지만 (아직 시도하지는 않았지만) Code에서 먼저 작동하지 않을 것으로 예상합니다 .

"Programming Entity Framework"의 저자 인 Julie Lerman의이 간단한 "결정 트리"는보다 확실한 결정을 내리는 데 도움이되어야한다고 생각합니다.

더 많은 정보는 여기에 있습니다.

데이터베이스 우선과 모델 우선은 실제로 차이가 없습니다. 생성 된 코드는 동일하며이 접근 방식을 결합 할 수 있습니다. 예를 들어, SQL 스크립트를 사용하여 데이터베이스를 변경하고 모델을 업데이트 할 수있는 것보다 디자이너를 사용하여 데이터베이스를 작성할 수 있습니다.

코드를 먼저 사용하면 레크리에이션 데이터베이스없이 모델을 변경하고 모든 데이터를 잃을 수 없습니다. IMHO,이 제한은 매우 엄격하며 프로덕션 환경에서 코드를 먼저 사용할 수 없습니다. 현재로서는 실제로 사용할 수 없습니다.

코드의 두 번째 작은 단점은 모델 빌더가 마스터 데이터베이스에 대한 권한을 요구한다는 것입니다. SQL Server Compact 데이터베이스를 사용하거나 데이터베이스 서버를 제어하는 ​​경우에는 영향을 미치지 않습니다.

먼저 코드의 장점은 매우 깨끗하고 간단한 코드입니다. 이 코드를 완전히 제어 할 수 있으며 뷰 모델로 쉽게 수정하고 사용할 수 있습니다.

버전 관리없이 간단한 독립형 응용 프로그램을 만들거나 프로덕션에서 수정이 필요한 프로젝트에서 model \ database를 먼저 사용하는 경우 코드 우선 접근 방식을 사용하는 것이 좋습니다.

http://www.itworld.com/development/405005/3-reasons-use-code-first-design-entity-framework 에서 관련 부품 인용

Entity Framework에서 코드 우선 디자인을 사용해야하는 3 가지 이유

1) 부스러기, 부풀림 감소

기존 데이터베이스를 사용하여 .edmx 모델 파일 및 관련 코드 모델을 생성하면 자동 생성 된 코드가 엄청나게 쌓입니다. 무언가를 깨뜨 리거나 차세대에 변경 사항을 덮어 쓰지 않도록 이러한 생성 된 파일을 절대 만지지 마십시오. 컨텍스트와 이니셜 라이저 도이 혼란에 갇혀 있습니다. 계산 된 읽기 전용 속성과 같이 생성 된 모델에 기능을 추가해야하는 경우 모델 클래스를 확장해야합니다. 이것은 거의 모든 모델에 대한 요구 사항이되며 모든 것에 대한 확장으로 끝납니다.

먼저 코드를 작성하면 직접 코딩 한 모델이 데이터베이스가됩니다. 구축하는 정확한 파일은 데이터베이스 디자인을 생성하는 것입니다. 추가 파일이 없으며 속성이나 데이터베이스에서 알 필요가없는 항목을 추가하려는 경우 클래스 확장을 만들 필요가 없습니다. 적절한 구문을 따르는 한 동일한 클래스에 추가 할 수 있습니다. 원하는 경우 Model.edmx 파일을 생성하여 코드를 시각화 할 수도 있습니다.

2) 더 큰 통제

DB를 처음 사용하면 응용 프로그램에서 사용하기 위해 모델에 생성 된 내용을 마음대로 사용할 수 있습니다. 때때로 명명 규칙이 바람직하지 않습니다. 때때로 관계와 협회는 당신이 원하는 것이 아닙니다. 다른 경우에는 지연 로딩과의 비 일시적 관계가 API 응답에 혼란을 초래합니다.

모델 생성 문제에 대한 해결책은 거의 항상 있지만 코드를 먼저 실행하면 시작부터 완벽하고 세밀한 제어가 가능합니다. 비즈니스 오브젝트의 안락함에서 코드 모델과 데이터베이스 디자인의 모든 측면을 제어 할 수 있습니다. 관계, 구속 조건 및 연관을 정확하게 지정할 수 있습니다. 속성 문자 제한과 데이터베이스 열 크기를 동시에 설정할 수 있습니다. 열망하거나 직렬화하지 않을 관련 모음을 지정할 수 있습니다. 요컨대, 더 많은 일에 책임이 있지만 앱 디자인을 완전히 제어 할 수 있습니다.

3) 데이터베이스 버전 관리

이것은 큰 것입니다. 버전 관리 데이터베이스는 어렵지만 코드 우선 및 코드 우선 마이그레이션으로 훨씬 효과적입니다. 데이터베이스 스키마는 코드 모델을 기반으로하기 때문에 소스 코드의 버전을 제어하여 데이터베이스 버전을 관리 할 수 ​​있습니다. 시드 고정 비즈니스 데이터와 같은 작업을 수행하는 데 도움이되는 컨텍스트 초기화를 제어해야합니다. 또한 코드 우선 마이그레이션을 생성해야합니다.

마이그레이션을 처음 활성화하면 구성 클래스와 초기 마이그레이션이 생성됩니다. 초기 마이그레이션은 현재 스키마 또는 기준 v1.0입니다. 이 시점부터 타임 순서가 지정되고 디스크립터로 레이블이 지정된 마이그레이션을 추가하여 버전 순서를 지정할 수 있습니다. 패키지 관리자에서 add-migration을 호출하면 UP () 및 DOWN () 함수 모두에서 코드 모델에서 변경된 모든 내용이 포함 된 새 마이그레이션 파일이 생성됩니다. UP 함수는 변경 사항을 데이터베이스에 적용하고 DOWN 함수는 롤백하려는 경우 동일한 변경 사항을 제거합니다. 또한 이러한 마이그레이션 파일을 편집하여 새 뷰, 인덱스, 저장 프로 시저 등의 추가 변경 사항을 추가 할 수 있습니다. 이들은 데이터베이스 스키마를위한 진정한 버전 관리 시스템이 될 것입니다.

코드 우선은 떠오르는 별인 것 같습니다. Ruby on Rails를 간략히 살펴 보았으며 데이터베이스 마이그레이션과 함께 표준이 코드 우선입니다.

MVC3 응용 프로그램을 구축하는 경우 코드가 먼저 다음과 같은 이점이 있다고 생각합니다.

• 손쉬운 속성 장식 -검증, 요구 등의 속성으로 필드를 장식 할 수 있습니다. EF 모델링에서는 매우 어색합니다.
• 이상한 모델링 오류가 없음-EF 모델링 에는 연결 속성의 이름을 바꾸려고 할 때와 같이 이상한 메타 데이터가있는 경우가 많으며 기본 메타 데이터와 일치해야합니다.
• 병합하기 어색하지 않음 -수은과 같은 코드 버전 제어 도구를 사용하는 경우 .edmx 파일 을 병합하는 것은 쉽지 않습니다 . C #에 익숙한 프로그래머이며 .edmx를 병합하고 있습니다. 코드 우선에서는 그렇지 않습니다.
• 먼저 코드와 대조하면 숨겨진 모든 복잡성과 미지의 문제없이 완벽하게 제어 할 수 있습니다.
• 패키지 관리자 명령 줄 도구를 사용하는 것이 좋습니다. 그래픽 도구를 사용하여 스캐 폴드보기에 새 컨트롤러를 추가하지 마십시오.
• DB-Migrations- 그런 다음 Enable-Migrations도 가능합니다. 이것은 너무 강력합니다. 코드에서 모델을 변경하면 프레임 워크에서 스키마 변경 내용을 추적 할 수 있으므로 스키마 버전이 자동으로 업그레이드 (필요한 경우 다운 그레이드)되어 업그레이드를 원활하게 배포 할 수 있습니다. (확실하지는 않지만 모델 우선으로도 작동합니다)

최신 정보

이 질문은 또한 코드 우선과 EDMX 모델 / db 우선의 비교를 요구합니다. 코드 우선은 이러한 두 가지 접근 방식에도 모두 사용할 수 있습니다.

• Model-First : POCO를 먼저 코딩 한 후 (개념적 모델) 데이터베이스 를 생성 합니다 (마이그레이션). 또는
• Database-First : 기존 데이터베이스가 있으면 POCO를 수동으로 코딩하여 일치시킵니다. (여기서 POCO가 자동으로 생성되지 않고 기존 데이터베이스를 제공한다는 점이 다릅니다). Entity Framework 또는 Entity Framework 5-기존 데이터베이스에서 POCO 클래스를 생성하는 방법을 사용하여 POCO 클래스 생성 및 기존 데이터베이스에 대한 매핑을 사용하여 자동으로 접근 할 수 있습니다 .

데이터베이스 구성을보다 유연하게 제어하고 제어하기 위해 EF 데이터베이스를 먼저 사용합니다.

먼저 EF 코드와 모델이 처음에는 시원해 보였고 데이터베이스 독립성을 제공하지만이 작업을 수행하면 매우 기본적이고 일반적인 데이터베이스 구성 정보로 간주하는 것을 지정할 수 없습니다. 예를 들어 테이블 인덱스, 보안 메타 데이터 또는 둘 이상의 열을 포함하는 기본 키가 있습니다. 나는 이것들과 다른 일반적인 데이터베이스 기능을 사용하고 싶기 때문에 데이터베이스 구성을 직접 수행해야합니다.

DB에서 처음 생성 된 기본 POCO 클래스는 매우 깨끗하지만 유용한 데이터 주석 속성이나 저장 프로 시저에 대한 매핑이 없습니다. 이러한 제한 사항 중 일부를 극복하기 위해 T4 템플릿을 사용했습니다. T4 템플릿은 특히 자신의 메타 데이터 및 부분 클래스와 결합 할 때 유용합니다.

모델은 먼저 많은 잠재력을 가지고있는 것처럼 보이지만 복잡한 데이터베이스 스키마 리팩토링 중에 많은 버그가 발생합니다. 이유가 확실하지 않습니다.

SP1 이전에는 큰 모델을 사용한 작업이 매우 느 렸습니다 (SP1 이후에는 시도하지 않았지만 지금은 매우 간단합니다).

나는 여전히 내 테이블을 먼저 디자인 한 다음 사내 구축 도구로 POCO를 생성하므로 각 poco 객체에 대해 반복적 인 작업을 수행 해야하는 부담이 있습니다.

소스 제어 시스템을 사용하는 경우 POCO의 이력을 쉽게 따를 수 있습니다. 디자이너가 생성 한 코드로는 쉽지 않습니다.

POCO를위한 기반이있어 많은 것들을 아주 쉽게 만들 수 있습니다.

나는 모든 테이블에 대한 뷰를 가지고 있으며, 각 기본 뷰는 외래 키에 대한 기본 정보를 가져오고 POCO는 POCO 클래스에서 파생됩니다. 이는 다시 유용합니다.

그리고 마지막으로 나는 디자이너를 좋아하지 않습니다.

데이터베이스 우선 접근 예 :

코드를 작성하지 않고 : ASP.NET MVC / MVC3 데이터베이스 우선 접근 방식 / 데이터베이스 우선

그리고이 접근법으로 데이터 손실이 적기 때문에 다른 접근법보다 낫다고 생각합니다.

IMHO 나는 모든 모델이 좋은 위치를 가지고 있다고 생각하지만 모델 첫 번째 접근 방식의 문제점은 데이터베이스 첫 번째 접근 방식을 사용하지 않고 응용 프로그램을 구축 할 수있는 유연성을 얻지 못하는 DBA가 데이터베이스를 제어하는 ​​많은 대기업에서 발생합니다. 나는 많은 프로젝트에서 일했고 배포에 관해서는 모든 권한을 원했습니다.

따라서 가능한 모든 변형 (코드 우선, 모델 우선, 데이터베이스)에 동의하는 한 실제 프로덕션 환경을 고려해야합니다. 따라서 시스템이 많은 사용자와 DBA가 쇼를 실행하는 대규모 사용자 기반 응용 프로그램이 될 경우 데이터베이스 우선 옵션을 내 의견으로 고려할 수 있습니다.

코드의 장점 중 하나는 Git과 같은 버전 제어 시스템에 대한 모든 변경 사항을 백업 할 수 있다는 것입니다. 모든 테이블과 관계는 본질적으로 클래스에 저장되므로 시간을 거슬러 올라가 데이터베이스의 구조가 무엇인지 확인할 수 있습니다.