엔티티 프레임 워크 병합 악몽

Question

우리는 엔티티 프레임 워크를 채택했으며 여러 사람이 개별 소스 컨트롤 분기에서 별도의 변경을 수행 할 때 병합시 병합 될 때 대량의 충돌이 발생하여 모델 파일이 손상 될 수 있다는 것을 발견했습니다 .

우리는 파일에 대해 독점적 인 체크 아웃을하는 방향으로 기울어 져 있지만, 나는 그것을 피하고 싶습니다. 내 질문은

...

이 거기에 더 나은이 더 나은 처리, 또는 우리가 취할 수있는 다른 방법이있을 것입니다 도구를 비교?

가능한 경우 입증 된 것을 찾고 있습니다.

새 업데이트 : 이 질문에 대한 여러분의 의견은 오래된 EF를 기반으로합니다. EDMX보다 DbContext를 사용하는 것이 좋습니다. 여기에 많은 정보가 있습니다. Database first 나 Code first의 단순성은 내 의견으로는 디자이너의 손실보다 훨씬 큽니다.

업데이트 : 파일에 대한 독점적 변경을 통해이 문제를 해결했습니다. 이 프로세스를 추가함으로써 우리는 모든 문제를 완전히 제거했습니다. 이것이 이상적인 솔루션은 아니지만 구현하기가 가장 쉽고 안정적이었습니다.

Answer 1

Craig Stuntz 여기에서 대부분의 문제를 일으키는 것은 디자이너 관련 XML (디자인 화면의 엔티티와 연결 등의 위치)입니다. 그러나 edmx:Runtime 요소 내의 충돌 해결은 매우 달성 가능합니다.

디자이너 관련 XML에서 충돌을 처리하는 가장 좋은 전략은 사용자 지정 레이아웃을 희생하고 기본 레이아웃으로 되 돌리는 것으로 완전히 무시하는 것입니다.

트릭은 <Diagrams> 요소의 모든 콘텐츠를 제거하는 것입니다. 디자이너는 문제없이 열어 기본 레이아웃을 적용합니다.

다음은 기본 레이아웃으로 열리는 EDMX 파일의 예입니다. <edmx:Runtime> 요소의 내용도 제거되었지만 이는 간결성을위한 것일 뿐이며 솔루션의 일부는 아닙니다.

<?xml version="1.0" encoding="utf-8"?> 
<edmx:Edmx Version="2.0" xmlns:edmx="http://schemas.microsoft.com/ado/2008/10/edmx"> 
    <!-- EF Runtime content --> 
    <edmx:Runtime> 
    <!-- Removed for brevity's sake only!--> 
    </edmx:Runtime> 
    <!-- EF Designer content (DO NOT EDIT MANUALLY BELOW HERE) --> 
    <Designer xmlns="http://schemas.microsoft.com/ado/2008/10/edmx"> 
    <Connection> 
     <DesignerInfoPropertySet> 
     <DesignerProperty Name="MetadataArtifactProcessing" Value="EmbedInOutputAssembly" /> 
     </DesignerInfoPropertySet> 
    </Connection> 
    <Options> 
     <DesignerInfoPropertySet> 
     <DesignerProperty Name="ValidateOnBuild" Value="true" /> 
     <DesignerProperty Name="EnablePluralization" Value="True" /> 
     <DesignerProperty Name="IncludeForeignKeysInModel" Value="True" /> 
     </DesignerInfoPropertySet> 
    </Options> 
    <!-- Diagram content (shape and connector positions) --> 
    <Diagrams> 
    </Diagrams> 
    </Designer> 
</edmx:Edmx> 

주 당신이 내가 기대 한 것이 무엇 인 디자이너의 컨텍스트 메뉴에서 Diagram | Layout Diagram을 선택하면 결과와 일치하지 않습니다 여기에 적용되는 기본 레이아웃.

업데이트 :Entity Framework 5부터이 방법이 조금 더 쉽습니다. 여기에 multiple diagram support을 추가하면 다이어그램 관련 xml이 별도의 파일로 분산됩니다. Entity Framework 업그레이드를 여러 번 경험 한 edmx 파일에는 여전히 오래된 다이어그램 관련 태그가 있습니다.Edmx 파일에서 Diagrams (어린이 포함)라는 태그를 간단히 삭제했습니다.

Answer 2

말씀 드린대로 한 가지 옵션은 파일을 잠그는 것입니다.

다른 가능한 옵션은 모든 모델 변경 사항을 팀의 한 개인에게 전달하는 것입니다.

또 다른 옵션은 파일을 작은 파일 (예 : 클래스 당 하나씩)로 나눠서 프로세스에서 일부 디자이너 지원을 남겨 둘 수 있습니다.

또 다른 옵션은 잠재적으로 XSLT를 사용하여 EDMX 파일을 변환하는 자체 프로세스를 만드는 것입니다. 그러나 이것이 정확히 어떻게 보이는지 모르겠는데, designer.cs 파일은 병합하기가 어렵습니다.

또 다른 옵션은 다른 ORM을 고려하는 것입니다.

EF의 다음 버전에서 개선 할 사항이 있는지 잘 모르겠습니다. 많은 양의 데이터를 하나의 파일에 던지더라도 어떤 종류의 확장 성을 의미하지는 않습니다. 그러나 LinqToSql은 똑같은 일을합니다.이 경우 Damien Guard는 파일을 분리하기 위해 T4 템플릿을 만들었지 만 EF와 비슷한 것이 있는지는 확실하지 않습니다.

Answer 3

저는 특히 EF에 익숙하지 않지만 울트라 범절 & 깨지기 쉬운 자동 생성 코드로 문제를 해결했습니다. 각각의 경우에 병합하는 방법에 대한 최선의 대답은 "하지 마세요"입니다. 두 가지 중 하나를 의미하는 시나리오에서 :

1) EF 코드가 한 방향으로 만 흐르도록 코드 프로모션 모델을 조입니다. 즉, 모든 충돌은 "원본 지점에서 복사"(AcceptTheirs) 또는 "대상을 변경하지 않음"(AcceptYours)으로 해결되며 모든 사람은 어떤 항목인지 미리 알아야합니다. 가장 일반적으로 새로 테스트 한 코드를 브랜치 트리의 안정 노드로 승격시킬 때 AcceptTheirs를, 그리고 불안정한/개발 브랜치로 픽스를 병합 할 때 AcceptYours를 원할 것입니다. (만약 개발 브랜치가 1보다 크다면 특정 브랜치에서 작업하는 팀이 소유 한 EF 코드 만이 후자의 규칙을 따르도록 항목을 분할하고 싶을 것입니다. 의도적으로 변경하지 않은 것은 다른 팀의 코드로 덮어 써야합니다 필요한 경우 AcceptTheirs를 사용하여 통합 분기에서 플로우됩니다.)

 
       /- [...] 
       /- v1.1 
      /- Release
 
    + Integration 
      - Dev1 
      - Dev2 
      - [...]
 

" Merge down, copy up"

2) 문자 그대로 병합하지 않는다; 프로세스에서 EF 코드를 완전히 제외하십시오. 분기를 통합 할 때 데이터베이스 및/또는 ORM을 변경해야하는 경우 데이터베이스에서 직접 프록시 클래스를 다시 생성하십시오. (물론 SQL 파일에 충돌하는 변경 사항을 해결하고 해결 한 후) Extreme 버전 : 병합 할 때가 아니라 모든 자동화 된 빌드 중에이 작업을 수행하십시오.

Answer 4

일부 strategies for dealing with large Entity Framework models in this article이 있습니다. 당신은 그들을 사용하는 것을 고려할 수 있습니다. 그러나 EDMX의 재생성과 관련된 대부분의 고통은 GUI 디자이너에서 끌어서 놓기를 통해 변경된 사항에서 비롯된 것으로 나타났습니다. 반면에 데이터베이스에서 모델 업데이트 또는 속성 창을 통해 작업하는 것은 상당히 합리적인 방식으로 변경하는 경향이 있으며 병합하기가 쉽지 않습니다.

가장 큰 문제점은 개념적/매핑/저장소 모델의 시각적 개체 모델에 대한 레이아웃 정보가 동일한 파일에 있다는 것입니다. 즉, 문제는 파일 자체의 크기 또는 엔티티 모델 자체에 대한 변경 사항이 아니라 GUI 디자이너에서 객체를 끌어다 놓을 때 발생하는 도매 재배치입니다. 나는 GUI 디자이너 레이아웃과 개념/매핑/스토리지 모델이 다른 파일에 있었으면 좋겠다. 나는 이것이 모델에 병합 변경과 함께 고통의 대부분을 제거 할 것이라고 생각합니다.

따라서 모델의 그래픽 레이아웃을 변경하지 않는 반 공식 정책이 있습니다. 이것은 손실이 많지 않습니다. 왜냐하면 모델에 수십 개 이상의 엔티티가있을 경우 한 페이지 만의 GUI 디자이너가 실제로 유용하지 않기 때문입니다. 그리고 확실히 병합을 훨씬 쉽게 만듭니다.

Entity Framework 버전 4에는 T4 템플릿을 기반으로 아티팩트 생성을 수행하는 옵션이 있습니다. 나는 전문가는 아니지만 GUI 레이아웃 정보를 T4 템플릿을 사용하여 다른 파일로 감추는 것이 가능할 수도 있습니다.

Answer 5

나는 사실상이 회사의 첫 번째 코드를 사용하도록 설득하려고 노력했지만 불행히도 종료되었습니다. 그들은 디자이너를 사용할 수있는 것을 좋아합니다. 불행히도 마지막 제품 배포시 문제가 발생하여 WCF 서비스 중 하나에 여러 소비자를 지원하기 위해 약 10 개의 끝점이 있고 병합 과정에서 EDMX 파일의 CS 섹션에 몇 개의 중복 항목이있었습니다 .

개인 프로젝트에서 나는 Code First 만 사용하고 있습니다. 나에게 그것은 자동 변속기보다 수동을 선호하는 것과 같은 이유 다. 물론 모델 디자이너는 (때로는 논의한 것처럼) 더 쉬울 수도 있지만 Code First를 사용하면 진행 상황을 훨씬 직접적으로 제어 할 수 있습니다. 수동 변속기처럼. :)