Entity Framework Merge Nightmare

Question

Hemos adoptado el Entity Framework y descubrimos que cuando varias personas realizan cambios aislados en sus ramas de control de origen individuales, hay conflictos masivos cuando se unen en una combinación, lo que da como resultado archivos de modelo rotos. .

Nos estamos inclinando en la dirección de forzar exclusiones exclusivas en el archivo, pero me gustaría evitar eso.

Mi pregunta es ...

¿Existe una mejor comparación de herramienta que manejar esto mejor, o hay otro enfoque que podríamos tomar?

Buscando algo que sea probado si es posible.

NUEVA ACTUALIZACIÓN: Para aquellos de ustedes que se encuentran con esta pregunta, se basa en el viejo EF. Sugiero pasar a usar DbContext sobre EDMX. Hay mucha información aquí en SO al respecto. La simplicidad de Database first o Code primero supera con creces la pérdida del diseñador en mi opinión.

ACTUALIZACIÓN: Resolvimos este problema forzando cambios exclusivos en el archivo. Al agregar este proceso, eliminamos por completo cualquier problema. Si bien esta no era la solución ideal, era la más confiable y fácil de implementar.

Answer 1

Craig Stuntz hace un buen trabajo al explicar que es el diseñador xml relacionado (las posiciones de entidades y asociaciones, etc. en la superficie de diseño) que causa la mayoría de los problemas aquí. Sin embargo, la resolución de conflictos dentro del elemento edmx:Runtime es muy alcanzable.

La mejor estrategia para tratar conflictos en el xml relacionado con el diseñador es omitirlos por completo sacrificando cualquier diseño personalizado y volviendo a un diseño predeterminado.

El truco consiste en eliminar todo el contenido del elemento <Diagrams>. El diseñador se abrirá sin ningún problema y aplicará un diseño predeterminado.

El siguiente es un ejemplo de un archivo EDMX que se abrirá con un diseño predeterminado. Tenga en cuenta que el contenido del elemento <edmx:Runtime> también se eliminó; sin embargo, esto solo se aplica a las brevidades, no forma parte de la solución.

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

Tenga en cuenta que el diseño predeterminado que se aplica aquí no coincide con la que se produce cuando se selecciona Diagram | Layout Diagram desde el menú contextual del diseñador que es lo que habría esperado.

Actualización: A partir del Entity Framework 5, esto se pone un poco más fácil. El multiple diagram support agregado allí descarga el diagrama relacionado xml a archivos separados. Tenga en cuenta que todavía tenía algunas etiquetas antiguas relacionadas con el diagrama en un archivo edmx que había experimentado una serie de mejoras de Entity Framework.Simplemente borré la etiqueta llamada Diagramas (incluidos los niños) del archivo edmx.

Answer 2

Como dijiste, una opción es bloquear el archivo.

Otra opción posible es enrutar todos los cambios del modelo a través de un individuo en el equipo.

Otra opción es dividir el archivo en archivos más pequeños (como uno por clase), posiblemente dejando algo de apoyo del diseñador en el proceso.

Otra opción es crear su propio proceso, posiblemente utilizando XSLT para transformar el archivo EDMX, pero no estoy seguro de cómo se vería exactamente, el archivo designer.cs es el más difícil de fusionar.

Otra opción es considerar un ORM diferente.

No estoy seguro de si están haciendo algo para mejorar esto en la próxima versión de EF. Tirar esa cantidad de datos en un solo archivo no implica escalabilidad de ningún tipo (Sin embargo, LinqToSql hace lo mismo: en ese caso, Damien Guard creó algunas plantillas T4 para separar el archivo, no estoy seguro de si algo similar existe para EF).

Answer 3

No estoy súper familiarizado con EF en particular, pero he tenido una buena cantidad de problemas con el código autogenerado frágil &. En cada caso, la mejor respuesta sobre cómo fusionarlo fue "do not". En su escenario, probablemente signifique una de dos cosas:

1) Ajuste su modelo de promoción de código para que el código EF solo fluya en una dirección. En otras palabras, cada conflicto se resolverá como "copia de la rama fuente" (Aceptar) o "mantener el objetivo sin cambios" (AceptarTus), y todos deben saber cuál es cuál de antemano. Lo más habitual es que acepte Aceptar al promocionar código recientemente probado hacia los nodos estables del árbol de sucursal y AcceptYours al fusionar correcciones con ramas inestables/de desarrollo. (Si hay> 1 rama de desarrollo, querrá particionar las cosas para que solo el código EF propiedad del equipo que trabaja en una rama determinada siga la última regla. Cualquier cosa que no esté alterando intencionalmente debe ser sobrescrita por el código de otros equipos que fluye desde la rama de integración, utilizando Aceptar si es necesario.)

 
       /- [...] 
       /- v1.1 
      /- Release
 
    + Integration 
      - Dev1 
      - Dev2 
      - [...]
 

" Merge down, copy up"

2) Literalmente no fusionarlas; excluir el código EF del proceso por completo. Cuando la integración de ramas requiere cambios en la base de datos y/o ORM, regenere las clases proxy directamente desde la base de datos. (después de resolver + generar cualquier cambio conflictivo en sus archivos SQL, por supuesto) Versión extrema: haga esto durante cada compilación automatizada, no solo al fusionarse.

Answer 4

hay algunas strategies for dealing with large Entity Framework models in this article. Podría considerar usarlos. Sin embargo, he descubierto que la mayor parte del dolor con la regeneración del EDMX proviene de los cambios realizados al arrastrar y soltar en el diseñador de GUI. Por otro lado, al actualizar el modelo de la base de datos o a través de la ventana de propiedades, se tienden a realizar cambios de manera bastante sensata y no suele ser difícil fusionarlos.

El mayor problema, por lo que yo puedo ver, es que la información de diseño para el modelo de objetos visuales en los modelos/mapeo/almacenamiento conceptuales están en el mismo archivo. En otras palabras, el problema no es tanto el tamaño del fichero o bien los cambios realizados en el propio modelo de entidad, pero el reordenamiento mayorista que sucede cuando se arrastra y coloca un objeto en el diseñador de interfaz gráfica de usuario. Me gustaría que el diseño del diseñador de GUI y los modelos conceptuales/de mapeo/almacenamiento estuvieran en diferentes archivos. Creo que esto eliminaría la mayor parte del dolor al fusionar los cambios en el modelo.

Por lo tanto, tenemos una política semi-oficial de no hacer cambios en el diseño gráfica del modelo. Esto no es una gran pérdida, porque cuando tienes más de una docena de entidades en tu modelo, el diseñador de GUI de una sola página no es realmente útil de todos modos. Y ciertamente hace que las fusiones sean mucho más fáciles.

versión 4 del marco de la entidad tendrá la opción de hacer la generación de artefactos basados ​​en plantillas T4. No soy un experto, pero puede ser posible convertir la información de diseño de la GUI en un archivo diferente usando una plantilla T4.

Answer 5

De hecho, traté de convencer a mi empresa de ir a Code First por esta misma razón, y se cerró, desafortunadamente. Les gusta poder usar el diseñador. Desafortunadamente, me encontré con problemas en nuestra última implementación de producción, donde uno de nuestros servicios WCF tiene alrededor de 10 puntos finales para admitir múltiples consumidores, y en el proceso de fusión, hubo varias entradas duplicadas en la sección CS del archivo EDMX. .

En mis proyectos personales, uso Code First exclusivamente. Para mí, es la misma razón por la que prefiero la transmisión manual a la automática. Claro, el diseñador de modelos puede ser más fácil (a veces, como ya hemos comentado), pero con Code First, usted obtiene un control mucho más directo de lo que está sucediendo. Al igual que una transmisión manual. :)