Pesadilla de fusión de Entity Framework

Hay algunas estrategias para tratar con modelos de large Entity Framework en este artículo. Podrías considerar usarlas. Sin embargo, he encontrado que la mayor parte del dolor con la regeneración de la EDMX proviene de los cambios realizados a través de arrastrar y soltar en el diseñador de la interfaz gráfica de usuario. Por otro lado, hacer Actualizar el Modelo desde la Base de datos o a través de la ventana de propiedades tiende a hacer cambios de una manera bastante sensata, y no tiende a ser difícil de combinar.

El mayor problema, como por lo que puedo ver, es que la información de diseño para el modelo de objeto visual en los modelos conceptuales/mapping/storage están en el mismo archivo. En otras palabras, el problema no es tanto el tamaño del archivo en sí o los cambios realizados en el modelo de entidad en sí, sino la reorganización general que ocurre cuando arrastra y suelta un objeto en el diseñador de la interfaz gráfica de usuario. Desearía que el diseño del diseñador gráfico y los modelos conceptuales / de mapeo / almacenamiento estuvieran en archivos diferentes. Creo que esto eliminaría la mayor parte de el dolor con la fusión de los cambios en el modelo.

Por lo tanto, tenemos una política semioficial de no hacer cambios en el diseño gráfico del modelo. Esto no es una gran pérdida, porque cuando tiene más de un par de docenas de entidades en su 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.

La versión 4 de Entity Framework tendrá la opción de generar artefactos basados en plantillas T4. No soy un experto, pero puede ser posible coaxir la información de diseño de la GUI en un archivo diferente utilizando una plantilla T4.

Como ha dicho, 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 soporte de diseñador en el proceso.

Otra opción es crear su propio proceso, potencialmente usando XSLT para transformar el archivo EDMX, pero no estoy seguro exactamente cómo se vería esto, el diseñador.el archivo cs es el enorme difícil de fusionar uno.

Otra opción es considerar un OR diferente.

No estoy seguro de si están haciendo algo para mejorar esto en la próxima versión de EF. Lanzar 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 existe algo similar para EF).

En realidad traté de convencer a mi empresa para ir al Código Primero por esta misma razón, y fue cerrado, por desgracia. Les gusta poder usar al diseñador. Desafortunadamente, me encontré con problemas en nuestro último despliegue de producción donde uno de nuestros servicios WCF tiene alrededor de 10 puntos finales para soportar múltiples consumidores, y en el proceso de fusión, hubo varias entradas duplicadas en la sección C-S del archivo EDMX.

En mis proyectos personales, estoy usando Código Primero exclusivamente. A yo, es la misma razón por la que prefiero la transmisión manual sobre la automática. Claro, el diseñador del modelo puede ser más fácil (a veces, como hemos discutido), pero con el código Primero, obtienes un control mucho más directo de lo que está pasando. Como una transmisión manual. :)

No estoy muy familiarizado con EF en particular, pero he tenido mi parte justa de problemas con el código autogenerado ultra detallado y frágil. En cada caso, la mejor respuesta sobre cómo fusionarlo fue "no". En su escenario eso probablemente significa 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 "copy from source branch" (AcceptTheirs) o "keep target unchanged" (AcceptYours), y todo el mundo debe saber cuál es cuál de antemano. Lo más común es que quieras aceptar Theirs cuando promociones código recién probado hacia los nodos estables del árbol de ramas y aceptar Theirs cuando combines correcciones a ramas inestables/de desarrollo. (Si hay > 1 rama de desarrollo, entonces querrá particionar las cosas para que solo el código EF propiedad del equipo que trabaja en una rama dada siga la última regla. Cualquier cosa que no estén alterando intencionalmente debe ser sobrescrita por el código de otros equipos fluyendo desde la rama de integración, usando AcceptTheirs si es necesario.)

               /- [...]
               /- v1.1
          /- Release

    + Integration
          - Dev1
          - Dev2
          - [...]

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