В идеале, то, как вы храните свои данные в базе данных, а затем то, как вы к ним обращаетесь, должно быть основано на характере отношений между сущностями домена в вашей доменной модели. То есть реляционная модель должна следовать из модели предметной области. Например, если у вас есть две сущности, скажем, Пользователь и Адрес.
Сценарий # 1 : Адрес никогда не доступен независимо, он всегда является атрибутом пользователя.
В этом случае Address - это объект-значение, а пользователь - это сущность, и есть инструкции о том, как сохранить эту связь. Один из способов - хранить атрибуты Address вместе с атрибутами User в одной таблице. В этом случае UserDao будет обрабатывать оба объекта.
Сценарий # 2 : Адрес может быть связан с пользователем, но также может быть отдельным объектом.
В этом случае необходим подход, отличный от первого. У вас может быть отдельный DAO и таблица для типа адреса.
Я хочу сказать, что чаще всего игнорируется эта важная идея о том, что Доменная Модель должна быть ядром приложения, управляя другими уровнями.
Например, если ваша модель предметной области правильно определена, и вы хорошо знаете тип сущностей, которые у вас есть, и отношения между ними, то ваша стойкость (реляционные таблицы и их отношения, ваши DAO и т. Д.) Будет развиваться как очень логичное следствие того, что вы имеете в доменной модели.
Другими словами, если вы потратите некоторое время на изучение вашей модели, вы сможете проследить свою проблему при определении того, как организовать ваши DAO в соответствии с моделью домена. Если вы сможете четко определить тип объектов и характер отношений между ними в доменной модели, это поможет вам решить вашу проблему на уровне DAL.