What to do with queries who don´t have a representation in a domain model?

Question

This is not specific to any language, it´s just about best practices. I am using JPA/Hibernate (but it could be any other ORM solution) and I would like to know how do you guys deal with this situation: Let´s supose that you have a query returning something that is not represented by any of your domain classes. Do you create a specific class to represent that specific query? Do you return the query in some other kind of object (array, map...) Some other solutions? I would like to know about your experiences and best practices.

P.S. Actually I am creating specific objetcs for specific queries.

Answer 1

I typically write a function that performs a query using SQL and then puts the results into either a list or dictionary (in Java, I'd use either an ArrayList or a HashMap).

If I found myself doing this a lot, I'd probably create a new file to hold all of these queries. Otherwise I'd just make them functions in whatever file they were needed/used.

Since we're talking Java specifically, I would certainly not create a new class in a separate file. However, for queries needed in only one class, you could create a private static inner class with only the function(s) needed to generate the query(s) needed by that class.

Answer 2

I'm finding the abstractness of the question hard to follow.

Do you have a specific example in mind?

Answer 3

The idea of wrapping that up the functionality in some sort of manager is always nice. It allows for better testing, and management therefore of schema changes.

Also allows for easier reuse in the application. NEVER just put the sql in directly!!!. For Hibernate I have found HQL great for just this. In particular , if you can use Named queries. Also be careful of adding an filter values etc use "string append", use parameters (can we say SQL injection ?). Even if the SQL is dynamic in terms of the join or where criteria, have a function in some sort of manager is always best.

Answer 4

We have a situation that sounds similar to yours.

We use separate objects for reporting data that spans several domain objects. Our convention is that these will be backed by a view in the database, so we have come to call them view objects. We generally use them for summarising complex data into a flat format.

Answer 5

@DrPizza

I will be more specific. We have three tables in a database

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

I have a query that returns a list of all projects but showing also some grouped information (all tasks, open tasks, closed tasks). When returned, the query looks like this

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

I don´t have any domain class that could represent this information and I don´t want to create specific methods in Project class (like getAllTasks, getOpenTasks) because each of these methods would trigger a new query. So the question is: I create a new class (somenthing like ProjectTasksQuery) just to hold that information? I return information within array or map? Something else?

Answer 6

You might feel better after reading about Data Transfer Objects. Some people plain don't like them, but if it feels like a good fit to you, it probably is.