Entity Framework Merge Nightmare

entity-framework merge tfs version-control

Frage

Wir haben das Entity Framework übernommen und haben festgestellt, dass, wenn mehrere Personen einzelne Änderungen in ihren einzelnen Quellcodeverwaltungszweigen vornehmen, es zu massiven Konflikten kommt, wenn sie in einer Zusammenführung zusammenkommen, was zu fehlerhaften Modelldateien führt.

Wir neigen dazu, exklusive Dateien aus der Datei zu erzwingen, aber ich möchte das vermeiden.

Meine Frage ist...

Gibt es ein besseres Vergleichstool, das dies besser bewältigen könnte, oder können wir einen anderen Ansatz verfolgen?

Suchen Sie nach etwas, das sich als möglich erweist.

NEUES UPDATE: Für diejenigen von Ihnen, die auf diese Frage stoßen, basiert sie auf alten EF. Ich schlage vor, DbContext über EDMX zu verwenden. Es gibt hier viele Informationen zu SO darüber. Die Einfachheit von Database First oder Code First überwiegt meiner Meinung nach bei weitem den Verlust des Designers.

UPDATE: Wir haben dieses Problem behoben, indem exklusive Änderungen an der Datei erzwungen wurden. Durch das Hinzufügen dieses Prozesses wurden alle Probleme vollständig beseitigt. Dies war zwar nicht die ideale Lösung, aber am zuverlässigsten und am einfachsten zu implementieren.

Akzeptierte Antwort

Craig Stuntz erklärt sehr gut, dass es sich bei dem Designer um xml (die Positionen von Entitäten und Assoziationen usw. auf der Entwurfsoberfläche) handelt, das hier die meisten Probleme verursacht. Die Konfliktlösung innerhalb des edmx:Runtime Elements ist jedoch sehr gut erreichbar.

Die beste Strategie für den Umgang mit Konflikten in der Designer-bezogenen XML-Datei besteht darin, diese vollständig zu umgehen, indem Sie jedes benutzerdefinierte Layout opfern und auf ein Standardlayout zurücksetzen.

Der Trick besteht darin, den gesamten Inhalt des <Diagrams> -Elements zu entfernen. Der Designer öffnet sich ohne Probleme und wendet ein Standardlayout an.

Das folgende Beispiel zeigt eine EDMX-Datei, die mit einem Standardlayout geöffnet wird. Beachten Sie, dass der Inhalt des <edmx:Runtime> -Elements ebenfalls entfernt wurde. Dies war jedoch nur der Kürze halber - es ist nicht Teil der Lösung.

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

Beachten Sie, dass das hier angewendete Standardlayout nicht mit dem Layout übereinstimmt, das bei Auswahl von Diagram | Layout Diagram angezeigt wird Diagram | Layout Diagram aus dem Kontextmenü des Designers, was ich erwartet hätte.

Update: Ab Entity Framework 5 wird dies etwas einfacher. Die hinzugefügte Unterstützung für mehrere Diagramme entlädt die xml für das Diagramm in separate Dateien. Beachten Sie, dass ich in einer edmx-Datei noch einige alte Diagramm-bezogene Tags hatte, bei denen mehrere Entity Framework-Aktualisierungen durchgeführt wurden. Ich habe einfach das Tag mit dem Namen Diagramme (einschließlich Kinder) aus der edmx-Datei gelöscht.


Beliebte Antwort

In diesem Artikel werden einige Strategien zum Umgang mit großen Entity Framework-Modellen beschrieben . Sie könnten sie in Betracht ziehen. Ich habe jedoch festgestellt, dass der größte Teil der Schmerzen bei der Regeneration des EDMX auf Änderungen zurückzuführen ist, die durch Ziehen und Ablegen des GUI-Designers vorgenommen wurden. Andererseits führt die Aktualisierung von Modell aus der Datenbank oder über das Eigenschaftenfenster dazu, dass Änderungen auf vernünftige Weise vorgenommen werden und das Zusammenführen nicht schwierig ist.

Das größte Problem, soweit ich sehen kann, ist, dass die Layoutinformationen für das visuelle Objektmodell in den Konzept- / Mapping- / Speichermodellen in derselben Datei liegen. Mit anderen Worten, das Problem liegt nicht so sehr in der Größe der Datei selbst oder in den Änderungen am Entitätsmodell selbst, sondern in der umfassenden Neuordnung, die beim Ziehen und Ablegen eines Objekts im GUI-Designer auftritt. Ich wünschte, das GUI-Designer-Layout und die konzeptionellen / Mapping- / Speichermodelle hätten unterschiedliche Dateien. Ich glaube, dies würde den größten Teil der Schmerzen durch das Zusammenführen von Änderungen am Modell beseitigen.

Daher haben wir eine halboffizielle Politik, das grafische Layout des Modells nicht zu ändern. Dies ist kein großer Verlust, denn wenn Sie mehr als ein paar Dutzend Objekte in Ihrem Modell haben, ist der GUI-Designer für eine Seite ohnehin nicht wirklich nützlich. Und das macht Zusammenführen sicherlich viel einfacher.

Version 4 des Entity Frameworks hat eine Option zur Artefaktgenerierung basierend auf T4-Vorlagen. Ich bin kein Experte, aber es ist möglich, die GUI-Layoutinformationen mithilfe einer T4-Vorlage in eine andere Datei zu überreden.



Lizenziert unter: CC-BY-SA with attribution
Nicht verbunden mit Stack Overflow
Ist diese KB legal? Ja, lerne warum
Lizenziert unter: CC-BY-SA with attribution
Nicht verbunden mit Stack Overflow
Ist diese KB legal? Ja, lerne warum