Шаблон проектирования DAO и использование его на нескольких таблицах

Я ищу отзыв о шаблоне проектирования объектов доступа к данным и используя его, когда вам нужно получить доступ к данным через несколько таблиц. Кажется, что этот шаблон, который имеет DAO для каждой таблицы вместе с объектом передачи данных (DTO), который представляет собой одну строку, не слишком полезен при работе с данными из нескольких таблиц. Я думал о создании составной DAO и соответствующей DTO, которая вернет результат, допустим, выполнить соединение на двух таблицах. Таким образом, я могу использовать SQL для захвата всех данных вместо первого захвата данных из одного с использованием одного DAO и второй таблицы с использованием второго DAO и составления их на Java.

Есть ли лучшее решение? И нет, я не могу перейти в Hibernate или другой инструмент ORM на данный момент. Просто прямо JDBC для этого проекта.

Ответ 1

Я бы согласился с вашим подходом. Мои DAO, как правило, выравниваются больше на уровне объекта, а не в перспективе таблицы DB. Я могу управлять несколькими объектами через DAO, но они, скорее всего, будут тесно связаны между собой. Нет причин не иметь SQL-доступ к двум таблицам, живущим в одном DAO.

И для записи я изгнал аббревиатуру DTO из моего словаря и кода.

Ответ 2

В идеале, как вы храните свои данные в базе данных, а затем, как вы обращаетесь к ним, должны быть получены из характера отношений между объектами домена в вашей модели домена. То есть реляционная модель должна следовать из модели домена. Например, если у вас есть два объекта, например "Пользователь и адрес".

Сценарий # 1: адрес никогда не обращается независимо, они всегда являются атрибутом пользователя. В этом случае Address - это объект Value, а User - Entity, и есть руководства по хранению этих отношений. Один из способов заключается в том, чтобы хранить адресные атрибуты Address наряду с атрибутами User в одной таблице. В этом случае UserDao будет обрабатывать оба объекта.

Сценарий №2: адрес может быть связан с пользователем, но также может быть отдельным самостоятельно. В этом случае необходим подход, отличный от первого. У вас может быть отдельный DAO и таблица для типа адреса.

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

Например, если ваша модель домена правильно определена, и вы хорошо знаете тип сущностей, которые у вас есть, и взаимосвязь между ними, то ваша постоянство (реляционные таблицы и их отношения, ваши DAO и т.д.) будет развиваться как очень логичное следствие того, что у вас есть в модели домена.

Другими словами, если вы потратите некоторое время на изучение своей модели, вы сможете проследить свою проблему при определении того, как организовать ваши DAO в месте в модели домена. Если вы можете четко определить тип объектов и характер отношений между ними в модели домена, он поможет вам решить вашу проблему в слое DAL.