實體框架合併夢魘

entity-framework merge tfs version-control

我們已經採用了實體框架,我們發現當多個人在他們各自的源控制分支中進行單獨的更改時,當它們在合併中聚集在一起時會發生大量衝突,導致模型文件損壞。

我們傾向於強制對文件進行獨占檢查,但我想避免這種情況。

我的問題是......

是否有更好的比較工具可以更好地處理這個問題,還是我們可以採取另一種方法?

尋找可能的事情。

新更新:對於遇到此問題的人,它基於舊的EF。我建議在EDMX上使用DbContext。這裡有很多關於它的信息。數據庫優先或代碼優先的簡單性遠遠超過了我認為設計師的損失。

更新:我們通過強制對文件進行獨占更改來解決此問題。通過添加此過程,我們完全消除了任何問題。雖然這不是理想的解決方案,但它是最可靠和最容易實施的。

一般承認的答案

Craig Stuntz很好地解釋了設計師相關的xml(設計界面上的實體和協會等的位置)導致了大部分問題。然而, edmx:Runtime元素內的衝突解決是非常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時產生的默認佈局不匹配設計師的上下文菜單中的Diagram | Layout Diagram是我所期望的。

更新:實體框架5開始 ,這會變得更容易一些。添加的多圖支持將圖表相關的xml卸載到單獨的文件中。請注意,我在edmx文件中仍然有一些舊的圖表相關標籤,這些標籤經歷了許多實體框架升級。我只是從edmx文件中刪除了名為Diagrams(包括children)的標籤。


熱門答案

本文中有一些處理大型Entity Framework模型的策略 。你可以考慮使用它們。但是,我發現EDMX再生的大部分痛苦都來自於GUI設計師通過拖放進行的更改。另一方面,從數據庫或通過屬性窗口執行更新模型傾向於以相當合理的方式進行更改,並且通常難以合併。

據我所知,最大的問題是概念/映射/存儲模型中可視對像模型的佈局信息在同一個文件中。換句話說,問題不在於文件本身的大小或對實體模型本身所做的更改,而是在GUI設計器上拖放對象時發生的批量重新排列。我希望GUI設計器佈局和概念/映射/存儲模型分成不同的文件。我相信這可以通過合併模型的變化來消除大部分的痛苦。

因此,我們有一個半官方的政策,即不對模型的圖形佈局進行更改。這並不是什麼損失,因為當你的模型中有超過幾十個實體時,無論如何只有一頁的GUI設計器才真正有用。它確實使合併變得容易多了。

實體框架的第4版將有一個基於T4模板進行工件生成的選項。我不是專家,但可以使用T4模板將GUI佈局信息哄騙到不同的文件中。



Related

許可下: CC-BY-SA with attribution
不隸屬於 Stack Overflow
這個KB合法嗎? 是的,了解原因
許可下: CC-BY-SA with attribution
不隸屬於 Stack Overflow
這個KB合法嗎? 是的,了解原因