Я использую инфраструктуру 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
;
Центром архитектуры являются модели, а не столы. Семантически, какая модель описывается или используется здесь?
это появляется чтобы получить список фотографий, с некоторой информацией об альбоме, включенной в элементы этого списка. Поэтому я подозреваю, что это связано с Photo
логическая модель Поэтому, куда бы вы ни поместили это в свою архитектуру и структуру, это должно быть семантически связано с этой моделью.
Как твой фреймворк определяет вещи в соответствии с этой структурой, поэтому я действительно не могу быть более конкретным. Разные фреймворки делают разные вещи по-разному. В целом, однако, в шаблоне MVC вы хотите построить свою логику и архитектуру вокруг моделей. А из этого запроса вы получите список фотографий (с дополнительной информацией), так что он связан с моделью фотографий.
модели Можно быть прямым однозначным представлением таблиц. Но они не необходимость быть. Похоже, вы искусственно ограничиваете свои модели, чтобы быть именно тем, что привело к этой проблеме. Может быть, вы продлите Photo
концепция модели для включения информации об альбоме? Может быть, вы создаете DTO, который является гибридом двух? Может быть, вы добавите Album
собственность на ваш Photo
модель? Существует много способов организации моделей. Дело в том, чтобы сохранить семантика из этих моделей ясно. Модели представляют доменные понятия (лайк Photo
), а не таблицы базы данных (например, photoTableModel
). Таблицы базы данных просто сохраняют информацию модели, которая будет восстановлена позже. Таким образом, база данных является край забота о домене, а не центральный один.
Других решений пока нет …