none
Opinion manejo de Objetos y consulta a BD RRS feed

  • Pregunta

  • Hola, estoy empezando hacer proyectos digamos algo mas grande, apelando a su experiencia mi duda es la siguiente; para proyectos pequeños siempre he trabajado con objetos por ejemplo: persona(10 columns), tratamiento(5 columns) ,... ; donde cada objeto representa una tabla en la DB, para una consulta de busqueda desde la aplicacion solia ubicar el id y traer las demas tablas dependientes, cargarlo y anidarlo en los objetos respectivos y usarlo a conveniencia en aplicacion, ahora tengo mas columnas y más tablas lo ideal seria trabajar de la misma forma? o hacer una consulta o procedure con joins, que me devuelva exactamente la consulta que deseo y recibirlo en un datatable. Como  lo hacen Uds.?? o cual seria la mejor forma de trabajar.

    Saludos.

    viernes, 29 de junio de 2018 15:46

Respuestas

  • Yo que nunca he optado por usar ORM's le puedo decir que:

    1. Sí, continúe trabajando con clases que representan tablas, pero nunca deje que el proceso se vuelva mecánico.  A veces una clase puede representar más de una tabla, o solamente parte de una tabla.  Siempre debe analizar la mejor posibilidad.
    2. He trabajado de ambas formas:  Crear consultas con joins y traer los objetos dependientes de una vez, o hacer la consulta del objeto maestro y luego traer los dependientes, y también he trabajado sin traer objetos dependientes.  Todas tienen ventajas y desventajas.

    Rápidamente, para #2, le cuento que cuando uso joins para traer todo en una consulta, pues me ahorro múltiples idas a la base de datos pero incremento el ancho de banda usado cuando transmito porque repito el registro maestro tantas veces como hijos hay.  Eso lo elimino trayendo primero el maestro, pero tengo que ir y volver al servidor una vez más.

    En los casos anteriores, ¿qué pasa si solamente ocupaba datos del maestro?  Gasté ancho de banda y otros recursos obteniendo datos dependientes que no necesité.  Ah y una vez ocupé data caching en una aplicación web y entonces tuve que sincronizar acceso a datos, lo que me enseñó lo delicado del asunto de múltiples consultas.

    Entonces creo que he llegado a la conclusión que lo mejor es no traer objetos dependientes automáticamente.  Una consulta, un tipo de registro.  Listo.  ¿Ocupo dependientes para un maestro-detalle?  Que el código lo solicite explícitamente.


    Jose R. MCP
    My GIT Repositories | Mis Repositorios GIT

    viernes, 29 de junio de 2018 15:58
    Moderador
  • hola

    >>ahora tengo mas columnas y más tablas lo ideal seria trabajar de la misma forma?

    ehh no lo aconsejaria

    >>hacer una consulta o procedure con joins, que me devuelva exactamente la consulta que deseo y recibirlo en un datatable. Como  lo hacen Uds.?

    no evaluaste entity framework ? creo que te ayudaria mucho en devolver entidades y sus relaciones

    ya no tendras que haycer ningun SELECT o JOIN a la db, entity framework lo hara por ti

    Introduction to Entity Framework

    recomendaria uses EF Code First, asi mpeas als entidades de forma controlada usando codigo

    Veras que al usar un ORM podrias indicar si la relacion se carga usando Lazy Load o prefieres indicar que se cargue cuando ejecute el linq

    saludos


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina

    lunes, 2 de julio de 2018 5:20

Todas las respuestas

  • Yo que nunca he optado por usar ORM's le puedo decir que:

    1. Sí, continúe trabajando con clases que representan tablas, pero nunca deje que el proceso se vuelva mecánico.  A veces una clase puede representar más de una tabla, o solamente parte de una tabla.  Siempre debe analizar la mejor posibilidad.
    2. He trabajado de ambas formas:  Crear consultas con joins y traer los objetos dependientes de una vez, o hacer la consulta del objeto maestro y luego traer los dependientes, y también he trabajado sin traer objetos dependientes.  Todas tienen ventajas y desventajas.

    Rápidamente, para #2, le cuento que cuando uso joins para traer todo en una consulta, pues me ahorro múltiples idas a la base de datos pero incremento el ancho de banda usado cuando transmito porque repito el registro maestro tantas veces como hijos hay.  Eso lo elimino trayendo primero el maestro, pero tengo que ir y volver al servidor una vez más.

    En los casos anteriores, ¿qué pasa si solamente ocupaba datos del maestro?  Gasté ancho de banda y otros recursos obteniendo datos dependientes que no necesité.  Ah y una vez ocupé data caching en una aplicación web y entonces tuve que sincronizar acceso a datos, lo que me enseñó lo delicado del asunto de múltiples consultas.

    Entonces creo que he llegado a la conclusión que lo mejor es no traer objetos dependientes automáticamente.  Una consulta, un tipo de registro.  Listo.  ¿Ocupo dependientes para un maestro-detalle?  Que el código lo solicite explícitamente.


    Jose R. MCP
    My GIT Repositories | Mis Repositorios GIT

    viernes, 29 de junio de 2018 15:58
    Moderador
  • hola

    >>ahora tengo mas columnas y más tablas lo ideal seria trabajar de la misma forma?

    ehh no lo aconsejaria

    >>hacer una consulta o procedure con joins, que me devuelva exactamente la consulta que deseo y recibirlo en un datatable. Como  lo hacen Uds.?

    no evaluaste entity framework ? creo que te ayudaria mucho en devolver entidades y sus relaciones

    ya no tendras que haycer ningun SELECT o JOIN a la db, entity framework lo hara por ti

    Introduction to Entity Framework

    recomendaria uses EF Code First, asi mpeas als entidades de forma controlada usando codigo

    Veras que al usar un ORM podrias indicar si la relacion se carga usando Lazy Load o prefieres indicar que se cargue cuando ejecute el linq

    saludos


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina

    lunes, 2 de julio de 2018 5:20
  • Tienes ya dos respuestas "opuestas": Una de Leandro que te dice "Utiliza un ORM" y otra de WebJose diciendo que nunca utiliza ORM. Yo te voy a dar una intermedia: Utiliza ORM para "las cosas normalitas", pero cuando haya que hacer alguna consulta crítica o compleja en la que el ORM no rinda lo suficiente, sáltate el ORM para esa consulta específica, escribiendo para ella una consulta SQL optimizada.

    Lo de traer o no traer objetos dependientes en la consulta, en Entity Framework se puede conseguir usando la carga "Lazy" (es el valor predeterminado) y añadiendo en la consulta un .Include(...) cuando quieras que te genere internamente un "join" para cargar los objetos dependientes de una sola vez.

    lunes, 2 de julio de 2018 6:54
    Moderador