エンティティフレームワークマージナイトメア

entity-framework merge tfs version-control

質問

Entity Frameworkを採用しましたが、複数の人が個々のソース管理ブランチに個別の変更を加えると、それらがマージされたときに大きな衝突が発生し、モデルファイルが壊れることがあります。

ファイルの排他的チェックアウトを強制する方向に傾いていますが、それは避けたいです。

私の質問は…

これをうまく処理するための、より優れた比較ツールはありますか。それとも、他にも可能なアプローチがありますか。

可能であれば証明されているものを探してください。

NEW UPDATE:この質問に出くわすあなたのそれらのために、それは古いEFに基づいています。私はEDMX上でDbContextを使うことに移行することを勧めます。それについてのSOに関する情報はここにたくさんあります。私の考えでは、データベースファーストまたはコードファーストの単純さが、デザイナーの損失をはるかに上回っています。

アップデート:ファイルに排他的な変更を強制することで、この問題を解決しました。このプロセスを追加することで、問題を完全に排除しました。これは理想的な解決策ではありませんでしたが、最も信頼性が高く実装が最も簡単な方法でした。

受け入れられた回答

クレイグ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 「レイアウト」を選択したときのレイアウトとは一致しませんDiagram | Layout DiagramデザイナーのコンテキストメニューからのDiagram | Layout Diagramは、私が期待していたものです。

更新: Entity Framework 5では、これは少し簡単になりました。そこに追加された複数のダイアグラムのサポートは別々のファイルにダイアグラム関連のxmlをオフロードします。いくつかのEntity Frameworkのアップグレードを経験したedmxファイルには、まだいくつかの古いダイアグラム関連のタグがあります。 edmxファイルからDiagrams(子を含む)という名前のタグを削除しただけです。


人気のある回答

この記事には、大規模なEntity Frameworkモデルを扱うためのいくつかの戦略があります。あなたはそれらを使うことを検討することができます。しかし、EDMXの再生成に関する問題のほとんどは、GUIデザイナーへのドラッグアンドドロップによる変更によるものです。一方、データベースから、またはプロパティウィンドウを介してモデルを更新すると、かなり賢明な方法で変更が行われる傾向があり、マージが困難になる傾向はありません。

私が見ることができる限り最大の問題は、概念モデル/マッピングモデル/格納モデルのビジュアルオブジェクトモデルのレイアウト情報が同じファイルにあることです。つまり、問題はファイル自体のサイズやエンティティモデル自体に対する変更ではなく、GUIデザイナにオブジェクトをドラッグアンドドロップしたときに起こる大きな再配置です。 GUIデザイナーのレイアウトと、概念/マッピング/格納モデルが異なるファイルになっていることを願います。私はこれがモデルへの変更をマージすることで苦痛のほとんどを除去すると信じています。

したがって、モデルのグラフィックレイアウトを変更しないという準公式の方針があります。モデルに2ダース以上のエンティティがある場合、1ページのみのGUIデザイナは実際にはあまり役に立ちませんので、これは大した損失ではありません。そしてそれは確かにマージをずっと簡単にします。

Entity Frameworkのバージョン4には、T4テンプレートに基づいてアーティファクトを生成するオプションがあります。私は専門家ではありませんが、T4テンプレートを使用してGUIレイアウト情報を別のファイルにまとめることは可能かもしれません。



Related

ライセンスを受けた: CC-BY-SA with attribution
所属していない Stack Overflow
ライセンスを受けた: CC-BY-SA with attribution
所属していない Stack Overflow