Отказ от ответственности: я не специалист по ORM ...
... но в классических отношениях многих ко многим вам не нужна третья модель данных (UserGroupAssoc).Класс User будет содержать коллекцию Group s:
public class User {
// ... user fields ...
List<Group> groups;
// ... getters/setters ...
}
Если вам необходимо также обратное отношение (группа содержит пользователей), класс Group будет выглядеть следующим образом:
public class Group {
// ... group fields ...
List<User> users;
// ... getters/setters ...
}
И снова, классический способ сделать это - использовать в коллекции «доменные объекты» (ваши DTO) (User и Group вместо userId и groupId).
Третий объект домена обычно требуется только в том случае, если таблица ассоциации (User_Group_Association) содержит что-то еще, кроме user_id и group_id (может быть, некоторый код авторизации, который позволил добавить пользователя в группу, что угодно):
user_id | group_id | auth_code
В этом случае класс UserGroupAssoc может иметь такую структуру:
public class UserGroupAssoc {
private User user;
private Group group;
private String authorizationCode;
// ... setters/getters ...
}
И отношение «многие ко многим» между User и Group преобразуетсядо двух отношений «один к одному» с этим новым объектом домена.Обычно доменные объекты предпочтительнее использовать (User и Group вместо userId и groupId).
Какой стандартный подход используется для реализации этого сценария?
Ну, если бы вы использовали ORM-фреймворк, это был бы стандартный способ, которым фреймворк делал это.Но , поскольку у вас есть собственное решение ORM, трудно сказать.
Хорошо ли объединение таблиц в дизайне DTO?
Почему проект DTO на уровне приложений должен зависеть от объединения таблиц в базе данных?Это случай несоответствия объектно-реляционного импеданса , а также, возможно, закона утечки абстракции , поскольку вы не можете полностью абстрагировать реляционную область в объектную область, сохраняя 1: 1переписка.
Некоторые считают, что один DTO должен соответствовать только ОДНОЙ таблице, а связанные объекты должны агрегироваться на уровне приложения.Это накладные расходы на выполнение нескольких выборок объектов из БД, верно?
ORM имеет некоторые ограничения (см. Снова несоответствие объектно-реляционного импеданса для некоторых проблем, с которыми вы можете столкнуться), и сложно моделировать ваши доменные объекты, чтобы приспособиться к ограничениям реляционной базы данных, или наоборот-versa.Отчеты являются хорошим примером в этом направлении.
Отчет обычно объединяет данные из нескольких таблиц.Это, конечно, не проблема для некоторых соединений SQL, но как вы собираетесь сопоставить результат с DTO?Как вы сами сказали ...
Всякий раз, когда DTO точно соответствует одной таблице в базе данных, это очень просто
... но отчетрезультат не будет сопоставлен с одной таблицей, он должен будет сопоставляться с фрагментами из нескольких таблиц.
В зависимости от ваших потребностей в приложении, вы можете получить странные классы или неуклюжиеSQLs.Вы можете выполнить больше запросов, чем необходимо для получения надлежащих объектных моделей и связей между ними;или у вас может быть больше подобных DTO только для того, чтобы ограничить число поездок в базу данных и повысить производительность.
Итак, я пытаюсь сказать (опять же, отказ от ответственности, что я не специалист ORM)что не все приложения являются хорошим кандидатом на ORM;но если вы подумаете о том, чтобы пойти дальше, возможно, посмотрите, как Hibernate / JPA решает проблемы, или даже используйте их вместо этого.