entity framework - tarda - ¿Cuáles son los beneficios de la carga lenta de ORM?

porque mi celular tarda en cargar

Question

Estoy investigando los fundamentos de la capa de datos para un nuevo sistema de informes basado en la web y he pasado mucho tiempo evaluando los ORM en los últimos días. Dicho esto, nunca he tratado con la "carga lenta" antes y estoy confundido sobre por qué es la configuración predeterminada para las consultas LINQ en Entity Framework. Parece que crea mucho tráfico de red y tareas innecesarias la base de datos con consultas adicionales que de otro modo podrían resolverse con combinaciones.

¿Alguien puede describir un escenario en el que la carga lenta sería beneficioso?

Algunos meta:

El nuevo sistema trabajará en contra de una base de datos con cientos de tablas y muchos terabytes de datos en un entorno de producción con más de 3.000 usuarios simultáneos en el sistema las 24 horas del día. Recopilarán grandes conjuntos de datos continuamente. ¿Es posible que un ORM simplemente no sea la solución adecuada para nuestras necesidades, especialmente porque la aplicación estará basada en la web?

Answer 1

Cuando hablamos de carga lenta, hablamos de Propiedades de navegación (cómo seguimos las claves externas). Lo que la carga lenta nos va a hacer es llenar la entidad desde una tabla remota mientras intentamos acceder a esa entidad. Por ejemplo, si tenemos un modelo como este

public class TestEntity
{
    public int Id{get;set;}
    public AnotherEntity RemoteEntity{get;set;}
}

Y llama a la siguiente

var something = WhateverContext.TestEntities.First().RemoteEntity;

Obtendremos 2 llamadas a la base de datos, una para WhateverContext.TestEntities.First() y otra para cargar la entidad remota.

Soy un chico de la web (y más específicamente un chico MVC) y para cosas de la web no creo que haya una buena razón para querer hacer esto, una llamada a la base de datos siempre será más rápida que dos si requerimos el mismo conjunto de datos.

La situación en la que creo que realmente vale la pena considerar la carga diferida es cuando no sabes cuándo realizas la primera consulta si necesitas la segunda entidad. En mi opinión, esto es mucho más relevante para las aplicaciones de Windows donde tenemos un usuario que realiza acciones en tiempo real (en lugar de un MVC sin estado donde los usuarios están solicitando páginas completas a la vez). Por ejemplo, creo que la carga diferida brilla cuando tenemos una lista de datos con un enlace de detalles, y luego no cargamos los detalles hasta que el usuario decide que quiere verlos.

No creo que esto se extienda a la paginación, clasificación y filtrado, IMO debe haber una consulta de base de datos específicamente diseñada por página de datos que está mostrando, que devuelve exactamente el conjunto de datos necesarios para mostrar esa página.

En términos de su pregunta de rendimiento, creo que EF (u otro ORM) probablemente pueda satisfacer sus necesidades aquí, pero debe tener cuidado con la forma en que está recuperando grandes conjuntos de datos debido a la forma en que EF rastrea las entidades. Eche un vistazo a mi hoja de referencia de ajuste de rendimiento EF y lea DetectChanges y AsNoTracking si decide usar EF con consultas grandes.

Answer 2

La mayoría de los ORM le dará la opción, cuando construya sus selecciones de objetos, de decir "no sea flojo, adelante y únase", por lo que si está preocupado desde una perspectiva de eficiencia, no se . Puedes hacer que funcione (generalmente).

Hay 2 casos particulares que conozco en los que la carga lenta me ayuda:

1. Encadenamiento de comandos ¿Qué ocurre si desea crear una selección básica, pero luego desea ejecutarla a través de una función de clasificación y filtrado basada en la información del usuario? Simplemente puede pasar el objeto ORM y adjuntarle la funcionalidad de clasificación y filtrado. En lugar de evaluarlo cada vez, solo evalúa cuándo se usa realmente.

2. Evitar consultas enormes, profundas y altamente relacionales ¿Qué sucede si solo necesita las ID de algunos campos relacionados? Si se carga de forma perezosa, no tiene que preocuparse de que se una a una gran cantidad de datos y tablas que no necesita, lo que puede ralentizar la consulta y sobreutilizar el ancho de banda. Por supuesto, si NECESITA todo lo demás, tendrá que ser explícito, o puede tener un problema donde ejecute perezosamente una consulta para cada registro de detalle. Como mencioné al principio, eso se supera fácilmente en cualquier ORM que valga la pena usar.

Answer 3

Un caso simple es un conjunto de resultados de N registros que no desea traer al cliente de una vez. El beneficio es que puede cargar de forma perezosa solo lo que se necesita para las demandas de los clientes, como ordenar, filtrar, etc. Un ejemplo sería una vista de paginación en la que se podrían recorrer los registros y ordenarlos en consecuencia, por lo tanto, el cliente solo necesita N cantidad en un momento dado.

Cuando realiza la consulta LINQ, traduce eso a comandos SQL en el servidor para proporcionar solo lo que se necesita en el contexto dado. Todo se reduce a la descarga de trabajo a la base de datos y minimizar lo que necesita enviar de vuelta al cliente.

Algunos argumentarán que la carga diferida basada en ORM es incorrecta, sin embargo, eso comienza a moverse hacia la semántica bastante rápido y debería ser más acerca del enfoque del diseño versus lo que está bien o mal .