Marco de entidades y objetos de acoplamiento

Question

Al construir una aplicación web que utiliza el marco de entidad en su capa de acceso a datos, se recomienda separar los objetos del contexto del objeto para permitir que los objetos sean recolectados.

Pero dado que las aplicaciones web son solicitudes de solicitud>> respuesta, el contexto del objeto ya no es referenciado por ningún objeto vivo después de enviar la respuesta al cliente, por lo que el contexto del objeto y su objeto adjunto deben ser disponible para la recolección de basura, ya que no hay ningún objeto vivo que haga referencia a ninguno de ellos.

¿Me falta algo aquí o no es necesario separar los objetos en tal escenario?

Answer 1

Sospecho que la orientación que viste estaba hablando de No-Tracking consultas de consultas

No-Tracking definitivamente tienen algunas ventajas de rendimiento de sitios web intensivos leer.

Los objetos son nunca y se les sigue por identidad, por lo que no es necesario separarlos, lo que evita el costo de resolver la identidad durante la materialización.

Una consulta sin seguimiento se parece a esto:

var source = ctx.Staff; 
source.MergeOption == MergeOption.NoTracking; 

var staff = (from s in source 
      where s.ID == 12 
      select s).First(); 

No hay consultas de seguimiento tienen otra ventaja sobre las entidades de desmontaje manual: separar manualmente desconecta la entidad del resto de su entidad Gráfico, en tanto que, sin el seguimiento consultas puede recuperar un gráfico conectado de entidades que están separadas.

Pero hay algunas desventajas para el uso de consultas de seguimiento no demasiado: vez en cuando puede terminar en situaciones en las que usted lee los resultados duplicados porque ha desactivado comparación de identidades.

Así que a menos que esté realmente seguro de que su consulta solo va a devolver una copia de cada entidad, debe tener cuidado, o puede terminar con un error de UI.

Esperanza esto ayuda

Alex

PD: Este tip on ObjectContext lifetime podría ser útil para usted.

Answer 2

Muhammad, no puedo hablar con el EF, pero en lo que se refiere a Linq-to-SQL, separar un objeto no tiene nada que ver con la recolección de basura. Tiene que ver con separar un objeto de un contexto de base de datos para que pueda ser adjuntado a otro objeto. Esto es algo muy común de hacer en una aplicación sin estado (n-tier). Lo mismo puede aplicarse al EF.

Randy

Answer 3

This article probablemente le ayudará. El EF se diseñó como NHibernate con una sesión/contexto con estado por defecto (es decir, una aplicación de formularios de Windows). Esto puede haber cambiado desde la versión 1, que fue la última vez que lo vi. Sin embargo, es un poco extraño, dado que la mayoría de las personas lo usará para sitios web, al igual que NHibernate hace que use sesiones por solicitud y no fue diseñado principalmente con sitios web en mente.

La idea es que no debe preocuparse por las actualizaciones o inserciones, todo se hace automáticamente. Eso aumenta el uso de la memoria, pero cuando su aplicación la administra adecuadamente, generalmente aumenta el rendimiento en lugar de reducirlo.

Answer 4

En el EF si tiene que usar más de un contexto como en una aplicación de n niveles, o si desea crear una entityCollection, necesita separar la entidad. Pero no es una implementación exigente para la aplicación asp.net

Answer 5

Suponiendo que no se mantiene el contexto del objeto (manteniendo una referencia a él de alguna manera), una vez que se sale del alcance será basura recolectada. No veo ninguna necesidad de separar entidades.

Entonces, no creo que te falte nada.