实体框架合并梦魇

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布局信息哄骗到不同的文件中。




许可下: CC-BY-SA with attribution
不隶属于 Stack Overflow
这个KB合法吗? 是的,了解原因
许可下: CC-BY-SA with attribution
不隶属于 Stack Overflow
这个KB合法吗? 是的,了解原因