El canonical answer en donde poner Database.SetInitializer llamadas está en para proyectos web. Estoy buscando otra opción.Evitar cirugía de escopeta con Database.SetInitializer
Estamos utilizando Entity Framework 4.3.1 con Code First. Escribimos servicios web y aplicaciones WinForms, y generalmente colocamos código de acceso a datos (como DbContexts) en bibliotecas compartidas.
En la actualidad, los constructores de nuestros descendientes DbContext este aspecto:
public PricingContext(string connectionString)
: base(connectionString)
{
Database.SetInitializer<PricingContext>(null);
}
95% del tiempo, que es el valor por defecto derecha. El 5% de las veces (algunas pruebas de integración, desarrollo totalmente nuevo, etc.) no lo es.
Si movemos ese código en la inicialización (o configuración) de nuestros servicios y aplicaciones, agregar un nuevo DbContext a una biblioteca implica Shotgun Surgery. Todos estos proyectos deben actualizarse, incluso si la biblioteca no expone el contexto directamente.
argumentos opcionales son una posibilidad:
public PricingContext(string connectionString,
IDatabaseInitializer<PricingContext> databaseInitializer = null)
: base(connectionString)
{
Database.SetInitializer<PricingContext>(databaseInitializer);
}
Anulación de la estrategia por defecto podría implicar pasar el inicializador a través de múltiples capas, sin embargo.
También hemos considerado crear un inicializador basado en la reflexión que ajuste todos los contextos a una estrategia específica.
¿Cuál es la mejor práctica?
¡Gracias! Después de intentar esto y mucho debate, decidimos ir a la configuración de inicializadores en las ubicaciones donde se están creando DbContexts (o donde se está configurando un contenedor DI/IoC). En ese punto, sabemos cuáles son los contextos. Entonces mi pregunta original se basó en suposiciones erróneas. – TrueWill