33

私たちは Entity Framework を採用しており、複数のユーザーが個々のソース管理ブランチに個別の変更を加えると、それらがマージされたときに大規模な競合が発生し、モデル ファイルが破損することがわかっています。

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

私の質問は...

これをより適切に処理するより優れた比較ツールはありますか、それとも別の方法がありますか?

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

新しい更新: この質問に出くわした人にとっては、古い EF に基づいています。EDMX 経由で DbContext を使用するように移行することをお勧めします。SOについては、ここに多くの情報があります。私の意見では、データベース ファーストまたはコード ファーストのシンプルさは、設計者の損失をはるかに上回ります。

更新: ファイルに排他的な変更を強制することで、この問題を解決しました。このプロセスを追加することで、問題を完全に解消しました。これは理想的なソリューションではありませんでしたが、最も信頼性が高く、実装が簡単でした。

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 が別のファイルにオフロードされます。いくつかの古いダイアグラム関連のタグが、Entity Framework のアップグレードを何度も経験した edmx ファイルに残っていることに注意してください。edmx ファイルから、Diagrams (子を含む) という名前のタグを削除しただけです。

于 2011-06-17T06:04:05.080 に答える
5

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

私の知る限り、最大の問題は、概念/マッピング/ストレージ モデルのビジュアル オブジェクト モデルのレイアウト情報が同じファイルにあることです。つまり、問題はファイル自体のサイズやエンティティ モデル自体に加えられた変更ではなく、GUI デザイナでオブジェクトをドラッグ アンド ドロップするときに発生する大規模な再配置です。GUI デザイナーのレイアウトと、概念/マッピング/ストレージ モデルが別のファイルにあることを望みます。これにより、モデルへの変更をマージする際の痛みのほとんどが解消されると思います。

したがって、モデルのグラフィック レイアウトを変更しないという半公式のポリシーがあります。モデルに数十を超えるエンティティがある場合、1 ページのみの GUI デザイナーはいずれにしてもあまり役に立たないため、これは大きな損失ではありません。そして、それは確かにマージをはるかに簡単にします.

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

于 2009-09-17T13:52:18.813 に答える
3

あなたが言ったように、1つのオプションはファイルをロックすることです。

別の可能なオプションは、すべてのモデル変更をチーム内の 1 人の担当者にルーティングすることです。

もう 1 つのオプションは、ファイルを小さなファイル (クラスごとに 1 つなど) に分割することです。これにより、デザイナーのサポートがプロセスに残される可能性があります。

もう 1 つのオプションは、独自のプロセスを作成することです。XSLT を使用して EDMX ファイルを変換する可能性がありますが、これがどのようになるか正確にはわかりません。

別のオプションは、別の ORM を検討することです。

EF の次のバージョンでこれを改善するために何かを行っているかどうかはわかりません。単一のファイルに大量のデータを投げることは、いかなる種類のスケーラビリティも意味しません (ただし、LinqToSql は同じことを行います。その場合、Damien Guard はファイルを分割するためにいくつかの T4 テンプレートを作成しましたが、同様のものが EF に存在するかどうかはわかりません)。

于 2009-09-16T18:21:27.967 に答える
1

私は特に EF に精通しているわけではありませんが、非常に冗長で脆弱な自動生成コードに関するかなりの問題を抱えています。いずれの場合も、どのようにマージするかについての最良の答えは「しない」でした。あなたのシナリオでは、おそらく次の2つのいずれかを意味します。

1) コード プロモーション モデルを強化して、EF コードが一方向のみに流れるようにします。言い換えれば、すべての競合は「ソース ブランチからコピーする」(AcceptTheirs) または「ターゲットを変更しない」(AcceptYours) のいずれかで解決されます。最も一般的には、新しくテストされたコードをブランチ ツリーの安定ノードに昇格させる場合は AcceptTheirs を使用し、修正を不安定/開発ブランチにマージする場合は AcceptYours を使用します。(1 つ以上の開発ブランチがある場合は、特定のブランチで作業しているチームが所有する EF コードのみが後者のルールに従うように、物事を分割する必要があります。意図的に変更していないものは、他のチームのコードで上書きする必要があります。必要に応じて AcceptTheirs を使用して、統合ブランチから流れます。) 

               /- [...]
               /- v1.1
          /- リリース

    + 統合
          - 開発1
          - Dev2
          - [...]
「マージダウン、コピーアップ」

2) 文字通りマージしないでください。プロセスから EF コードを完全に除外します。ブランチを統合するためにデータベースや ORM の変更が必要な場合は、プロキシ クラスをデータベースから直接再生成します。(もちろん、競合する SQL ファイルへの変更を解決してビルドした後) エクストリーム バージョン: マージ時だけでなく、すべての自動ビルド中にこれを行います。

于 2009-09-17T03:27:51.763 に答える
1

私は実際に、まさにこの理由で自分の会社を Code First に移行するよう説得しようとしましたが、残念ながら閉鎖されました。彼らは、デザイナーを使用できることを気に入っています。残念ながら、WCF サービスの 1 つに複数のコンシューマーをサポートするために約 10 個のエンドポイントが含まれているという前回の実稼働展開で問題が発生しました。マージの過程で、EDMX ファイルの CS セクションにいくつかの重複したエントリがありました。 .

私の個人的なプロジェクトでは、Code First のみを使用しています。私にとって、オートマチックトランスミッションよりもマニュアルトランスミッションを好むのと同じ理由です。確かに、モデル デザイナーの方が簡単かもしれませんが (前述のように、場合によっては)、コード ファーストを使用すると、何が起こっているかをより直接的に制御できます。まるでマニュアルトランスミッションのようです。:)

于 2012-04-20T15:19:47.863 に答える