Question

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

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

我的问题是......

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

寻找可能的证据。

NEW UPDATE： 对于那些遇到这个问题的人来说，它基于旧的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时产生的布局不匹配，这是我所期望的。

更新：从Entity Framework 5开始，这会变得更容易一些。添加的multiple diagram support将图表相关的xml卸载到单独的文件中。请注意，我仍然在edmx文件中有一些旧的图表相关标签，这些标签经历了许多实体框架升级。我只是从edmx文件中删除了名为Diagrams（包括children）的标签。

Answer 2

有一些strategies for dealing with large Entity Framework models in this article。你可以考虑使用它们。但是，我发现EDMX再生的大部分痛苦都来自于GUI设计师通过拖放进行的更改。另一方面，从数据库或通过属性窗口进行更新模型往往会以相当明智的方式进行更改，并且往往难以合并。

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

因此，我们有一个半官方的政策，即不对模型的图形布局进行更改。这并不是什么损失，因为当你的模型中有超过几十个实体时，无论如何只有一页的GUI设计器才真正有用。它确实使合并变得更加容易。

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

Answer 3

正如你所说，一个选项是锁定文件。

另一种可能的选择是通过团队中的一个人路由所有模型更改。

另一个选择是将文件分成更小的文件（例如每个类一个），可能会在此过程中留下一些设计师支持。

另一个选择是创建自己的进程，可能使用XSLT来转换EDMX文件，但是我不确定这看起来是什么样的，designer.cs文件很难合并。

另一种选择是考虑不同的ORM。

我不确定他们是否会在下一版EF中做任何改进。在单个文件中投入大量数据并不意味着任何类型的可扩展性（但LinqToSql也做同样的事情 - 在这种情况下，Damien Guard创建了一些T4模板来分解文件，不确定EF是否存在类似的东西）。 / p>

Answer 4

我对EF并不是特别熟悉，但我对超级详细的问题有很大的帮助。脆弱的自动生成代码。在每种情况下，关于如何合并它的最佳答案是“不要”。在您的场景中，这可能意味着两件事之一：

1）收紧代码促销模型，使EF代码只向一个方向流动。换句话说，每个冲突都将被解析为“从源分支复制”（AcceptTheirs）或“保持目标不变”（AcceptYours），并且每个人都应该知道哪个是提前的。最常见的是，当将新测试的代码提升到分支树的稳定节点时，您需要接受它们;当将修复程序合并到不稳定/开发分支时，您将希望接受它们。（如果有> 1个开发分支，那么你将需要对事物进行分区，以便只有在给定分支中工作的团队拥有的EF代码遵循后一个规则。任何他们不是故意改变的东西都应该被其他团队覆盖从集成分支流出的代码，必要时使用AcceptTheirs。）

               /- [...]
               /- v1.1
          /- Release

    + Integration
          - Dev1
          - Dev2
          - [...]

“Merge down, copy up”

2）字面上不要合并它们;完全从流程中排除EF代码。集成分支需要更改数据库和/或ORM时，直接从数据库重新生成代理类。（当然，在解析+构建对SQL文件的任何冲突更改之后）极限版本：在每次自动构建期间执行此操作，而不仅仅是在合并时。

Answer 5

我实际上试图说服我的公司因为这个原因去了Code First，但很遗憾被关闭了。他们喜欢能够使用设计师。不幸的是，我在上一次生产部署中遇到了问题，其中我们的一个WCF服务中有大约10个端点以支持多个消费者，并且在合并过程中，EDMX文件的CS部分中有几个重复的条目

在我的个人项目中，我只使用Code First。对我来说，这与我更喜欢手动而不是自动变速器的原因相同。当然，模型设计师可能更容易（有时，正如我们所讨论的那样），但使用Code First，您可以更直接地控制正在发生的事情。就像手动变速器一样。：）

实体框架合并梦魇

5 个答案: