¿Qué hacer con las consultas que no tienen una representación en un modelo de dominio?

Question

Esto no es específico de ningún idioma, solo se trata de las mejores prácticas. Estoy usando JPA/Hibernate (pero podría ser cualquier otra solución ORM) y me gustaría saber cómo manejan ustedes esta situación: Supongamos que tiene una consulta que devuelve algo que no está representado por ninguna de tus clases de dominio ¿Creas una clase específica para representar esa consulta específica? ¿Devuelve la consulta en algún otro tipo de objeto (matriz, mapa ...) Algunas otras soluciones? Me gustaría conocer sus experiencias y mejores prácticas.

P.S. En realidad estoy creando objetos específicos para consultas específicas.

Answer 1

Normalmente escribo una función que realiza una consulta usando SQL y luego coloca los resultados en una lista o diccionario (en Java, usaría una ArrayList o una HashMap).

Si me encontré haciendo esto mucho, probablemente crearía un nuevo archivo para contener todas estas consultas. De lo contrario, solo los haría funciones en cualquier archivo que fueran necesarios/usados.

Como estamos hablando específicamente de Java, ciertamente no crearía una nueva clase en un archivo separado. Sin embargo, para las consultas necesarias en una sola clase, puede crear una clase interna estática privada con solo la (s) función (es) necesaria (s) para generar la (s) consulta (s) que necesita esa clase.

Answer 2

La idea de resumir la funcionalidad en algún tipo de administrador siempre es agradable. Permite una mejor prueba y, por lo tanto, la administración de los cambios de esquema.

También permite una reutilización más fácil en la aplicación. NUNCA acaba de poner el sql directamente! Para Hibernate, he encontrado HQL ideal para esto. En particular, si puede usar consultas con nombre. También tenga cuidado de agregar un filtro de valores, etc. use "string append", use parámetros (¿podemos decir inyección de SQL?). Incluso si el SQL es dinámico en términos de los criterios de unión o donde, tener una función en algún tipo de administrador siempre es lo mejor.

Answer 3

Tenemos una situación que suena similar a la suya.

Usamos objetos separados para informar datos que abarcan varios objetos de dominio. Nuestra convención es que estos estarán respaldados por una vista en la base de datos, por lo que hemos llegado a llamarlos objetos de vista. Generalmente los usamos para resumir datos complejos en un formato plano.

Answer 4

@DrPizza

voy a ser más específico. Tenemos tres tablas en una base de datos

USER 
PROJECT 
TASK 
USER to TASK 1:n 
PROJECT to TASK 1:n 

Tengo una consulta que devuelve una lista de todos los proyectos, pero que muestra también algunos datos agrupados (todas las tareas, las tareas abiertas, tareas cerrado). Cuando regresó, la consulta se parece a esto

PROJECTID: 1 
NAME: New Web Site 
ALLTASK: 10 
OPENTASK: 7 
CLOSEDTASK: 3 

No tengo ninguna clase de dominio que podría representar esta información y que no quieres para crear métodos específicos de la clase de proyecto (como getAllTasks, getOpenTasks) porque cada uno de estos métodos desencadenarían una nueva consulta. Entonces la pregunta es: Creo una nueva clase (algo así como ProjectTasksQuery) solo para contener esa información? Devuelvo información dentro de una matriz o un mapa? ¿Algo más?

Answer 5

Puede sentirse mejor después de leer acerca de Data Transfer Objects. Algunas personas plain don't like them, pero si se siente como una buena opción para usted, probablemente sí lo sea.