entity-framework - entity framework cargar objetos relacionados

Por qué las propiedades de navegación son virtuales por defecto en EF

Question

He seguido la clase de POCO que se usa en EF 6.x.

Mi pregunta : ¿Por qué la propiedad de navegación de ''Publicaciones'' en la entidad ''Blog'' se declara virtual?

public class Blog 
{  
    public int BlogId { get; set; }  
    public string Name { get; set; }  
    public string Url { get; set; }  
    public string Tags { get; set; }  

    public virtual ICollection<Post> Posts { get; set; }  
}

Answer 1

Si define su propiedad de navegación virtual , Entity Framework creará en el tiempo de ejecución una nueva clase (proxy dinámico) derivada de su clase y la usará en lugar de su clase original. Esta nueva clase creada dinámicamente contiene lógica para cargar la propiedad de navegación cuando se accede por primera vez. Esto se conoce como "carga perezosa". Permite que Entity Framework evite cargar un árbol completo de objetos dependientes que no son necesarios de la base de datos.

En algunas circunstancias, es mejor usar "Carga impaciente", especialmente si sabes que estarás interactuando con objetos relacionados en algún momento.

Julie Lerman realmente es la autoridad en todo lo relacionado con Entity Framework, y explica este proceso muy bien en su artículo de MSDN Desmitificando estrategias de Entity Framework: Cargando datos relacionados

La carga impaciente con Include es útil para los escenarios en los que sabe de antemano que desea los datos relacionados para todos los datos principales que se consultan. Pero recuerda los dos posibles inconvenientes. Si tiene demasiados Incluye o rutas de navegación, el Entity Framework puede generar una consulta de bajo rendimiento. Y debe tener cuidado al devolver más datos relacionados de lo necesario gracias a la facilidad de codificación con Include.

La carga perezosa recupera muy convenientemente los datos relacionados tras bambalinas para usted en respuesta al código que simplemente hace mención de los datos relacionados. También hace que la codificación sea más simple, pero debe ser consciente de la interacción que está causando con la base de datos. Puede causar 40 viajes a la base de datos cuando solo uno o dos eran necesarios.

Si está desarrollando una aplicación web en la que cada comunicación con el servidor es un nuevo contexto, la carga diferida solo creará una sobrecarga innecesaria para mantener la clase dinámica para los objetos relacionados que nunca se cargarán. Muchas personas deshabilitarán la carga perezosa en estos escenarios. En última instancia, aún es mejor evaluar las consultas de SQL que EF ha creado y determinar qué opciones funcionarán mejor para el escenario en el que se está desarrollando.