33

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

我们倾向于强制对文件进行独家签出，但我想避免这种情况。

我的问题是...

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

如果可能的话，寻找可以证明的东西。

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

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

4

5 回答 5

17

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开始，这变得更容易了。在那里添加的多图表支持将与图表相关的 xml 卸载到单独的文件中。请注意，我在 edmx 文件中仍然有一些与图表相关的旧标签，这些标签已经经历了多次实体框架升级。我只是从 edmx 文件中删除了名为 Diagrams（包括子项）的标签。

于 2011-06-17T06:04:05.080 回答
5

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

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

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

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

于 2009-09-17T13:52:18.813 回答
3

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

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

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

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

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

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

于 2009-09-16T18:21:27.967 回答
1

我对 EF 并不是特别熟悉，但我在超冗长和脆弱的自动生成代码方面遇到了相当多的问题。在每种情况下，如何合并它的最佳答案是“不要”。在您的场景中，这可能意味着以下两件事之一：

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

               /- [...]
               /- v1.1
          /- 释放

    + 整合
          - 开发1
          - 开发2
          - [...]
“向下合并，向上复制”

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

于 2009-09-17T03:27:51.763 回答
1

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

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

于 2012-04-20T15:19:47.863 回答