实体框架合并梦魇

Question

我们已经采用了实体框架,我们发现当多个人在他们各自的源控制分支中进行单独的更改时,当它们在合并中聚集在一起时会发生大量冲突,导致模型文件损坏.

我们倾向于强制对文件进行独占检查,但我想避免这种情况.

我的问题是......

是否有更好的比较工具可以更好地处理这个问题,还是我们可以采取另一种方法？

寻找可能的事情.

新更新: 对于遇到此问题的人,它基于旧的EF.我建议在EDMX上使用DbContext.这里有很多关于它的信息.数据库优先或代码优先的简单性远远超过了我认为设计师的损失.

更新: 我们通过强制对文件进行独占更改来解决此问题.通过添加此过程,我们完全消除了任何问题.虽然这不是理想的解决方案,但它是最可靠和最容易实施的.

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从设计器的上下文菜单中选择时产生的默认布局不匹配,这是我所期望的.

更新:从实体框架5开始,这会变得更容易一些.添加的多图支持将图表相关的xml卸载到单独的文件中.请注意,我在edmx文件中仍然有一些旧的图表相关标签,这些标签经历了许多实体框架升级.我只是从edmx文件中删除了名为Diagrams(包括children)的标签.

Answer 2

本文中有一些处理大型实体框架模型的策略。您可以考虑使用它们。但是，我发现EDMX再生的大部分痛苦来自于通过拖放GUI设计器进行的更改。另一方面，从数据库或通过属性窗口执行更新模型倾向于以相当合理的方式进行更改，并且合并起来并不容易。

据我所知，最大的问题是概念/映射/存储模型中视觉对象模型的布局信息位于同一文件中。换句话说，问题不仅仅在于文件本身的大小或对实体模型本身所做的更改，而在于在GUI设计器上拖放对象时发生的批量重新安排。我希望GUI设计器布局和概念/映射/存储模型位于不同的文件中。我相信这将消除合并模型更改带来的大部分麻烦。

因此，我们有一个半官方的政策，即不对模型的图形布局进行更改。这并不是什么大的损失，因为当您的模型中有多个实体时，仅一页的GUI设计器实际上并没有什么用。这无疑使合并变得容易得多。

实体框架的第4版将具有一个选项，可以基于T4模板生成构件。我不是专家，但是可以使用T4模板将GUI布局信息哄骗到另一个文件中。