Несколько состав бобов или бобов в качестве интерфейса

Question

В моей компании есть таблицы, компоненты для этих таблиц и запросы SQL, использующие эти компоненты в качестве выходных данных и эти таблицы в качестве входных данных (iBatis, myBatis, ..).

Как обычно, я создаю объектный компонент для каждой таблицы, которую я использую в приложении.

Но когда в SQL-запросе используется, например, 7 таблиц, мне нужно создать композицию из 7 компонентов. И если другой запрос использует 4 разных таблицы, я должен создать еще одну композицию из 4 бинов.

Теперь мне интересно, нужно ли мне иметь столько составов, сколько несколько табличных кортежей в запросах, которые имеет приложение.

Я думал о бинах как о интерфейсе для решения этой проблемы, но это не представляется возможным.

Пример задачи:

Таблицы ЗАКАЗЧИК, АВТОМОБИЛЬ, ЗАКАЗЧИК, РИТЕЙЛЕР, ЗАКАЗЧИК, ...

ВЫБЕРИТЕ customer.name, retailer.name, car.name WHERE ...

Чтобы обработать вывод этого запроса для этих объектов:

public CustomerRetailerCar {

    private Customer customer;
    private Car car;
    private Retailer retailer;

}

Так что у меня много композиций, и я чувствую, что не решаю эту проблему правильно. Я не прав?

Любой совет приветствуется.

Answer 1

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

А именно, если у каждого Customer есть Car, то в бобе Customer должно быть поле, подобное:

private Car car

Если Customer может иметь несколько машин, поле должно быть набором Car с.

И то же самое для Customer <-> Retailer ассоциации.

В этом случае, когда вам нужно вернуть клиентов с сопутствующими автомобилями и продавцами, вам не нужно создавать новый класс. Картограф должен вернуть существующий объект Customer с установленными полями car и retailer.

Примеры того, как отобразить это в mybatis, приведены в примеров в документации