¿Es Entity Framework Code First un poco sin sentido / inútil en la producción y cuál es una buena estrategia de EF para la producción?

Recientemente he estado programando con Entity Framework 4.1 Code First y me encanta su desarrollo, pero con solo un plan final y una lista de características que cambia rápidamente, estoy modificando constantemente la Clase / Base de datos para satisfacer las necesidades de las aplicaciones.

En el desarrollo, no hay datos en vivo y puedo eliminar fácilmente toda la base de datos para que se vuelva a crear con el nuevo esquema, sin embargo, obviamente, en vivo, ¡esto es muy malo!

Las únicas soluciones que puedo ver son soltar la tabla de metadatos y mantener la base de datos sincronizada manualmente o, básicamente, soltar y reiniciar.

Personalmente prefiero el primer método, ya que creo que será mucho más fácil agregar una columna / tabla que recrear y migrar datos, pero, a menos que me haya perdido algo, esto se aleja completamente de Code First.

Entonces, la pregunta realmente es, ¿es Code First solo sobre el desarrollo inicial y cuál es una buena estrategia para administrar EF para un entorno de producción?

frameworks entity-framework

— wilhil
fuente

Preguntarte esto durante unos días, no estaba segura de si era mejor aquí o desbordamiento de pila ...

— wilhil

Respuestas:

Mi opinión es que la creación automática de la base de datos del código primero es solo para el desarrollo. Respondí preguntas similares en Stack Overflow donde describí cómo actualizar la base de datos y por qué la funcionalidad automática es mala en la producción:

La actualización de la base de datos es una tarea semi-manual. No debería haber magia automática no probada detrás; además, EF 4.1 actualmente no tiene tal magia disponible (solo hay una presentación sobre las características en las que está trabajando el equipo de ADO.NET).

También puede consultar esta pregunta para comprender mejor cómo se actualizan los sitios web.

— Ladislav Mrnka
fuente

¡Hola de nuevo! -¡Eres rápido en las preguntas de EF! :) ... ¡No sé dónde estaría sin ti!

— wilhil

Unos meses después y mi programa está bastante terminado ... Estoy marcando esto como respuesta, pero me preguntaba si algo ha cambiado / ¿hay algún recurso que pueda ayudar?

— wilhil

Se lanzó la primera vista previa pública de "Migraciones". blogs.msdn.com/b/adonet/archive/2011/07/27/…

— Ladislav Mrnka

Gracias, mirando eso ahora! Me encantó desarrollar con Code First, pero estoy muy nervioso / preocupado por cambiar más tarde.

— wilhil

¿Cómo maneja el caso en que los StoredProcs o las Vistas se crean directamente en la base de datos para otros fines, por ejemplo, informes que la aplicación no utiliza? Necesitaríamos saber qué SP están afectados primero por un cambio de esquema en el código.

— softveda

Mantener scripts de actualización .

En la propia base de datos, mantenga una tabla donde se guarde un registro con la versión del esquema.

Cuando inicia la aplicación, detecta la versión contra la versión que se supone que deben utilizar los binarios. Si difiere, ejecuta (o le pide al usuario) los scripts de actualización.

No olvide hacer una copia de seguridad de la base de datos primero.

Siguiente paso: estás despedido;) Las actualizaciones de la base de datos no deberían ocurrir automáticamente sin una copia de seguridad primero, y posiblemente en tiempo de inactividad, no cuando UN USUARIO ejecuta una versión más nueva. Su enfoque es perfecto: cerrar implementaciones más grandes con toneladas de errores.

— TomTom

@TomTom: eso depende. Llevamos varios años ejecutando sin problemas una aplicación de base de datos que hace exactamente esto: cambios automáticos de esquema para una nueva versión, realizada por la aplicación cuando detecta una versión demasiado antigua. Las copias de seguridad se realizan diariamente, y mantenemos todos los cambios de esquema compatibles con versiones anteriores (solo agregamos campos y tablas, nunca eliminamos ninguno). Estoy de acuerdo en que las medidas que mencionó son importantes cuando los cambios no son compatibles con versiones anteriores, y no puede garantizar que todas las aplicaciones cliente se actualicen simultáneamente (por ejemplo, para bases de datos de grandes empresas).

— Doc Brown

En la parte superior si los cambios no son triviales. Intente cambiar un campo en una tabla de 2tb (y sí, me encargo de esto, y ni siquiera es un almacén de datos). Te has metido en un escenario donde estás acumulando deudas técnicas porque solo puedes AGREGAR campos, nunca limpiar.

— TomTom

La pregunta es de alguna manera defectuosa ya que establece conexiones entre el modelo de programación y el entorno de tiempo de ejecución donde no hay ninguno.

El código primero es principalmente un controlador de velocidad de desarrollo y no está realmente conectado al sistema de tiempo de ejecución.

En producción, tendrá una configuración adecuada que niega al tiempo de ejecución la posibilidad de eliminar / actualizar el modelo db.

— casper
fuente