Что делать с запросами, которые не имеют представления в модели предметной области?

Question

Это не относится к какому-либо языку, речь идет только о лучших практиках. Я использую JPA / Hibernate (но это может быть любое другое решение ORM), и я хотел бы знать, как вы, ребята, справляетесь с этой ситуацией: Предположим, у вас есть запрос, возвращающий что-то, что не представлено ни одним из ваших классов доменов. Вы создаете определенный класс для представления этого конкретного запроса? Вы возвращаете запрос в каком-либо другом виде объекта (массив, карта ...) Некоторые другие решения? Я хотел бы узнать о вашем опыте и лучших практиках.

P.S. На самом деле я создаю конкретные объекты для конкретных запросов.

Answer 1

У нас есть ситуация, похожая на вашу.

Мы используем отдельные объекты для представления данных, охватывающих несколько объектов домена. Наше соглашение состоит в том, что они будут поддерживаться представлением в базе данных, поэтому мы пришли, чтобы называть их объектами представления. Обычно мы используем их для суммирования сложных данных в единый формат.

Answer 2

Возможно, вы почувствуете себя лучше, прочитав о Объектах передачи данных . Некоторым людям просто они не нравятся , но если вам это кажется подходящим, то, вероятно, это так.

Answer 3

@ DrPizza

Я буду более конкретным. У нас есть три таблицы в базе данных

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

У меня есть запрос, который возвращает список всех проектов, но показывает также некоторую сгруппированную информацию (все задачи, открытые задачи, закрытые задачи). При возврате запрос выглядит так

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

У меня нет класса домена, который мог бы представлять эту информацию, и я не хочу создавать конкретные методы в классе Project (например, getAllTasks, getOpenTasks), потому что каждый из этих методов будет инициировать новый запрос. Итак, вопрос: Я создаю новый класс (такой как ProjectTasksQuery) только для хранения этой информации? Я возвращаю информацию в массиве или карте? Что-то еще?

Answer 4

Идея обернуть эту функциональность в своего рода менеджера всегда хороша. Это позволяет улучшить тестирование и, следовательно, управлять изменениями схемы.

Также позволяет упростить повторное использование в приложении. НИКОГДА не вставляйте sql напрямую !!!. Для Hibernate я нашел HQL отлично подходит именно для этого. В частности, если вы можете использовать именованные запросы. Также будьте осторожны при добавлении значений фильтра и т. Д. Используйте «string append», используйте параметры (можно сказать, SQL-инъекция?) Даже если SQL является динамическим с точки зрения объединения или критериев, иметь функцию в каком-либо диспетчере всегда лучше.

Answer 5

Обычно я пишу функцию, которая выполняет запрос с использованием SQL, а затем помещает результаты либо в список, либо в словарь (в Java я бы использовал ArrayList или HashMap).

Если бы я часто этим занимался, я бы, вероятно, создал новый файл для хранения всех этих запросов. В противном случае я бы просто сделал их функциями в любом файле, в котором они были нужны / использованы.

Поскольку мы говорим конкретно о Java, я бы, конечно, не создавал новый класс в отдельном файле. Однако для запросов, необходимых только в одном классе, вы можете создать закрытый статический внутренний класс, содержащий только те функции, которые необходимы для генерации запроса (запросов), необходимого для этого класса.