Entité Cadre Merge Nightmare

entity-framework merge tfs version-control

Question

Nous avons adopté Entity Framework et nous constatons que, lorsque plusieurs personnes effectuent des modifications isolées dans leurs branches de contrôle de source individuelles, il existe des conflits énormes lorsqu'elles fusionnent pour créer des fichiers de modèle cassés.

Nous nous efforçons d'imposer des vérifications exclusives au dossier, mais j'aimerais éviter cela.

Ma question est...

Existe-t-il un meilleur outil de comparaison qui permettrait de mieux gérer cela, ou existe-t-il une autre approche que nous pourrions adopter?

Vous cherchez quelque chose qui est prouvé si possible.

NOUVELLE MISE À JOUR: Pour ceux d’entre vous qui rencontrent cette question, elle est basée sur le vieil EF. Je suggère de passer à l’utilisation de DbContext sur EDMX. Il y a beaucoup d'informations ici sur SO à ce sujet. La simplicité de la base de données d'abord ou du code d'abord l'emporte de loin sur la perte du concepteur à mon avis.

MISE À JOUR: Nous avons résolu ce problème en imposant des modifications exclusives au fichier. En ajoutant ce processus, nous avons complètement éliminé tous les problèmes. Bien que cette solution ne soit pas idéale, elle était la plus fiable et la plus simple à mettre en œuvre.

Réponse acceptée

Craig Stuntz explique bien que c’est le XML lié au concepteur (les positions des entités et associations, etc. sur l’aire de conception) qui est à l’origine de la plupart des problèmes qui se posent ici. La résolution des conflits au sein de l’élément edmx:Runtime est toutefois très réalisable.

La meilleure stratégie pour traiter les conflits dans le XML lié au concepteur consiste à les contourner complètement en sacrifiant toute disposition personnalisée et en rétablissant une disposition par défaut.

L'astuce consiste à supprimer tout le contenu de l'élément <Diagrams> . Le concepteur s'ouvrira sans problème et appliquera une mise en page par défaut.

Voici un exemple de fichier EDMX qui s’ouvrira avec une présentation par défaut. Notez que le contenu de l' <edmx:Runtime> a également été supprimé, mais que ce n'était que pour des raisons de concision, il ne fait pas partie de la solution.

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

Notez que la présentation par défaut appliquée ici ne correspond pas à celle obtenue lorsque vous sélectionnez Diagram | Layout Diagram de configuration du menu contextuel du concepteur, ce à quoi je m'attendais.

Mise à jour: à partir de Entity Framework 5 , cela devient un peu plus facile. La prise en charge de plusieurs diagrammes ajoutée à cet emplacement décharge le XML lié au diagramme en fichiers séparés. Notez que, dans un fichier edmx, il y avait encore d'anciennes balises liées aux diagrammes qui avaient subi un certain nombre de mises à niveau Entity Framework. J'ai simplement supprimé la balise nommée Diagrammes (y compris les enfants) du fichier edmx.


Réponse populaire

Dans cet article, il existe certaines stratégies pour gérer les grands modèles Entity Framework . Vous pourriez envisager de les utiliser. Cependant, j’ai constaté que la régénération d’EDMX est le principal inconvénient des modifications apportées par glisser-déposer sur le concepteur d’interface graphique. D'autre part, mettre à jour le modèle à partir de la base de données ou via la fenêtre de propriétés a tendance à apporter des modifications assez sensibles et n'a pas tendance à être difficile à fusionner.

Le plus gros problème, à ma connaissance, est que les informations de disposition du modèle d'objet visuel dans les modèles conceptuel / mappage / stockage se trouvent dans le même fichier. En d'autres termes, le problème n'est pas tant la taille du fichier lui-même ou les modifications apportées au modèle d'entité lui-même, mais le réarrangement global qui se produit lorsque vous faites glisser un objet sur le concepteur d'interface graphique. Je souhaite que la disposition du concepteur d'interface graphique et les modèles conceptuels / de mappage / de stockage soient placés dans différents fichiers. Je pense que cela éliminerait la plupart des problèmes liés à la fusion des modifications apportées au modèle.

Par conséquent, nous avons une politique officieuse consistant à ne pas modifier la présentation graphique du modèle. Ce n'est pas vraiment une perte, car lorsque vous avez plus d'une douzaine d'entités dans votre modèle, le concepteur d'interface graphique d'une page seulement n'est de toute façon pas vraiment utile. Et cela facilite certainement les fusions.

La version 4 de Entity Framework aura une option pour générer des artefacts basés sur des modèles T4. Je ne suis pas un expert, mais il est peut-être possible de convertir les informations de disposition de l'interface graphique dans un fichier différent à l'aide d'un modèle T4.



Related

Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow