实体框架合并噩梦

Question

我们采用了实体框架，我们发现当多个人在各自的源代码控制分支中进行孤立的更改时，当他们合并在一起时会出现巨大的冲突，从而导致模型文件损坏。

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

我的问题是......

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

如果可能的话，寻找经过验证的东西。

新更新： 对于那些遇到这个问题的人来说，它是基于旧的 EF 的。我建议转而使用 DbContext 而不是 EDMX。这里有很多关于它的信息。在我看来，数据库优先或代码优先的简单性远远超过了设计者的损失。

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

Answer 1

克雷格·斯图茨 很好地解释了设计器相关的 xml（实体和关联等在设计表面上的位置）导致了这里的大多数问题。然而，edmx:Runtime 元素内的冲突解决是非常容易实现的。

处理设计器相关 xml 中的冲突的最佳策略是通过牺牲任何自定义布局并恢复为默认布局来完全绕过它们。

技巧是删除 元素的所有内容。设计器将毫无问题地打开并应用默认布局。

以下是将使用默认布局打开的 EDMX 文件的示例。请注意， 元素的内容也被删除，但这只是为了简洁起见 - 它不是解决方案的一部分。

<?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>

请注意，此处应用的默认布局与选择“图表 | 图表”时生成的布局不匹配。设计器上下文菜单中的布局图正是我所期望的。

更新：从Entity Framework 5开始，这得到容易一点。 多图表支持 在那里添加将图表相关的 xml 卸载到单独的文件中。请注意，我在 edmx 文件中仍然有一些与图表相关的旧标签，这些标签经历了多次实体框架升级。我只是从 edmx 文件中删除了名为“Diagrams”（包括子项）的标签。

Answer 2

有一些 本文中处理大型实体框架模型的策略。你可以考虑使用它们。然而，我发现 EDMX 重新生成的大部分痛苦来自于通过 GUI 设计器上的拖放进行的更改。另一方面，从数据库或通过属性窗口执行更新模型往往会以相当合理的方式进行更改，并且合并并不困难。

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

因此，我们有一个半官方政策，不更改模型的图形布局。这并不是什么太大的损失，因为当您的模型中有几十个以上的实体时，一页的 GUI 设计器无论如何都没有真正的用处。它确实使合并变得更加容易。

实体框架版本 4 将提供基于 T4 模板生成工件的选项。我不是专家，但可以使用 T4 模板将 GUI 布局信息导入到不同的文件中。

Answer 3

正如您所说，一种选择是锁定文件。

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

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

另一种选择是创建您自己的流程，可能使用 XSLT 来转换 EDMX 文件，但我不确定这到底是什么样子，designer.cs 文件是非常难以合并的文件。

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

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

Answer 4

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

在我的个人项目中，我专门使用 Code First。对我来说，这就是我更喜欢手动变速箱而不是自动变速箱的原因。当然，模型设计者可能会更容易（有时，正如我们所讨论的），但是通过 Code First，您可以更直接地控制正在发生的事情。就像手动变速箱一样。 :)

Answer 5

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

1) 收紧您的代码升级模型，以便 EF 代码仅朝一个方向流动。换句话说，每个冲突都将被解决为“从源分支复制”（AcceptTheirs）或“保持目标不变”（AcceptYours），每个人都应该提前知道哪个是哪个。最常见的是，当将新测试的代码提升到分支树的稳定节点时，您需要 AcceptTheirs；当将修复合并回不稳定/开发分支时，您需要 AcceptYours。 （如果有 >1 个开发分支，那么您需要对事物进行分区，以便只有在给定分支中工作的团队拥有的 EF 代码才遵循后一个规则。他们无意更改的任何内容都应该被其他团队覆盖来自集成分支的代码，如有必要，请使用 AcceptTheirs。）

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

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

"Merge down, copy up"

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