Gente, perdón que me meta en esta discusión, pero quería preguntarles como resuelven por ejemplo la levantada de información para un reporte ?, supongamos este mismo caso, un reporte de clientes donde una de las columnas es el Vendedor. Ponen en movimiento todo el dominio para esto?

 

Gracias.

 

Sebastian Renzi

 

 


De: patrones@mug.org.ar [mailto:patrones@mug.org.ar] En nombre de Esteban A. Zibecchi
Enviado el: domingo, 24 de septiembre de 2006 17:19
Para: patrones List Member
Asunto: [patrones] Lazy Load

 

Lo mismo nos pasa a nosotros ya que implementamos IdentityMap. En la operación de LazyLoad lo consultamos de manera indirecta ya que el que maneja el IdentityMap es el mismo DataMapper.

 

Saludos

Esteban

 

 


From: patrones@mug.org.ar [mailto:patrones@mug.org.ar] On Behalf Of Diego Cepero
Sent: Sábado, 16 de Septiembre de 2006 08:08
To: patrones List Member
Subject: [patrones] Lazy Load

Ahora entiendo.

 

Imagino que el escenario en el que encontrás problemas involucra la recuperación de gran cantidad de clientes, sin embargo, para mí, en una asociación como esa no debería ser tan costoso el lazy-load, porque normalmente existen pocos vendedores para muchos clientes... entonces una muy buena parte de las peticiones de lazy-load las estaría satisfaciendo el Identity Map.

 

Te pregunto entonces, ¿estás usando un identity map? ¿lo consultás en la operación de lazy-load?

 


De: Esteban A. Zibecchi [mailto:[EMAIL PROTECTED]
Enviado el: Viernes, 15 de Septiembre de 2006 07:08 p.m.
Para: patrones List Member
Asunto: [patrones] Lazy Load

Supongamos que tenemos una entidad : Cliente que contiene a otra entidad : Vendedor.

 

La solucion que estamos viendo es levantar Cliente y luego cerrar el DataReader y recorrer los Clientes uno por uno y levantar entonces con un nuevo DataReader su Vendedor.

 

Esto permite tener siempre un solo DataReader abierto simultáneamente.

 

Saludos

Esteban

 


From: patrones@mug.org.ar [mailto:patrones@mug.org.ar] On Behalf Of Diego Cepero
Sent: Viernes, 15 de Septiembre de 2006 07:45
To: patrones List Member
Subject: [patrones] Lazy Load

No te entiendo bien, tirá un ejemplo para ubicarme en el caso.

 


De: Esteban A. Zibecchi [mailto:[EMAIL PROTECTED]
Enviado el: Jueves, 14 de Septiembre de 2006 07:33 p.m.
Para: patrones List Member
Asunto: [patrones] Lazy Load

Es cierto, el tema es cuando son en cascada. Para eso mejor levantar la estructura y luego irla aplanando.

 

Saludos

Esteban

 


From: patrones@mug.org.ar [mailto:patrones@mug.org.ar] On Behalf Of Diego Cepero
Sent: Jueves, 14 de Septiembre de 2006 08:05
To: patrones List Member
Subject: [patrones] Lazy Load

Hola Esteban,

 

    Hasta donde sé, la única forma de tener dos readers abiertos (en versiones de SQL Server anteriores a 2005), es que usen conexiones distintas. Entonces, imagino que tus mappers deberían, en la operación "LazyLoad()",  abrir la conexión, cargar la relación y después cerrar la conexión.

 

    Un abrazo.

 


De: Esteban A. Zibecchi [mailto:[EMAIL PROTECTED]
Enviado el: Miércoles, 13 de Septiembre de 2006 06:31 p.m.
Para: patrones List Member
Asunto: [patrones] Lazy Load

Hi Listeros!

 

Disculpen que moleste con este tema pero mi experiencia es casi nula con respecto a ORMs y hay algo que me llamó la atención del framework que usamos nosotros para trabajar.

 

En nuestro framework utilizamos DataMappers - siguiendo los consejos de Fowler - y lo que noté es que cuando levanto las entidades SIEMPRE estoy recurriendo al uso del LazyLoad.

 

Analizando por qué siempre hacemos esto es porque en .NET no se pueden tener 2 DataReaders abiertos y entonces cuando estoy levantando un cliente (por ejemplo), si quisiera levantar su vendedor simultáneamente tendría que abrir otro DataReader y pincha.....

 

Hay alguien que esté usando DataMappers también? Cómo manejaron este problema? Y lo ORMs? que hacen?

 

Saludos

Esteban

 



__________ Información de NOD32, revisión 1.1773 (20060925) __________

Este mensaje ha sido analizado con NOD32 antivirus system
http://www.nod32.com


__________ Información de NOD32, revisión 1.1773 (20060925) __________

Este mensaje ha sido analizado con NOD32 antivirus system
http://www.nod32.com

Responder a