Где разместить SQL-запросы, объединяющие несколько таблиц?

Я использую инфраструктуру MVC и имею photo Таблица SQL и album Таблица SQL. Запросы для photo столик в photoTableModel класс и запросы для album столик в albumTableModel учебный класс.

Где я могу разместить запросы, которые используют обе таблицы?

Например, следующий запрос использует обе таблицы. Поместить ли запрос в photoTableModel, albumTableModelновая модель стола или, может быть, даже услуга?

SELECT `photo`.`id`
, `photo`.`name`
FROM `photo`
JOIN `album`
ON `album`.`album_id` = `photo`.`album_id`
AND `album`.`album_id` = 1
;

2

Решение

Центром архитектуры являются модели, а не столы. Семантически, какая модель описывается или используется здесь?

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

Как твой фреймворк определяет вещи в соответствии с этой структурой, поэтому я действительно не могу быть более конкретным. Разные фреймворки делают разные вещи по-разному. В целом, однако, в шаблоне MVC вы хотите построить свою логику и архитектуру вокруг моделей. А из этого запроса вы получите список фотографий (с дополнительной информацией), так что он связан с моделью фотографий.

модели Можно быть прямым однозначным представлением таблиц. Но они не необходимость быть. Похоже, вы искусственно ограничиваете свои модели, чтобы быть именно тем, что привело к этой проблеме. Может быть, вы продлите Photo концепция модели для включения информации об альбоме? Может быть, вы создаете DTO, который является гибридом двух? Может быть, вы добавите Album собственность на ваш Photo модель? Существует много способов организации моделей. Дело в том, чтобы сохранить семантика из этих моделей ясно. Модели представляют доменные понятия (лайк Photo), а не таблицы базы данных (например, photoTableModel). Таблицы базы данных просто сохраняют информацию модели, которая будет восстановлена ​​позже. Таким образом, база данных является край забота о домене, а не центральный один.

2

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]