-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Модели в фреймворках
- Автор темы StalkerClasses
- Дата начала
@Вурдалак Если отложить в сторону запись (вообще отложить). Для модели чтения как получать данные из базы для создания модели? Писать все прямыми запросами (или через квери билдер не принципиально) или использовать готовые методы data mapper-а (не обязательно один метод и не обязательно одного дата меппера)?
А нафига??? Месье любитель писать тонны однотипного кода? Я понимаю что для некоторых случаев нужны прямые запросы, но всетаки в более половины случаев (а иногда и в более 90%) для получения данных, необходимых для модели достаточно простого вызова метода из репозитория/датамеппера/тейблгейтвея.
А если речь идет о зависимых данных + когда колонки перечисляемые, поддерживать эти зависимости сразу в нескольких местах напряжно. Основной косяк такого подхода что приходится полностью скрывать методы и функционал связанный с обновлением записей в датамеппере и часто это вообще не тривиально или не возможно без правки исходников. Сейчас нет вообще ни одного орм-а или датамеппера с возмоностью работать в отдельном режиме, заточенном под чтение с иммутабельными записями, всегда приходится костылить. Т.е. хорошо чтобы было единое описание схемы и связей как и для обычного датамеппера, так и для заточенного только под чтение, но такого нет
представь себе страничку (профиль пользователя), представь модель страницы.
представь команду "Добавить в друзья", осознай, что представленная модель для этой задачи не подходит
это разные модели, да можно вытянуть профиль, языки, колво друзей, ... и добавить метод "Добавить в друзья (ид)" только нафига тянуть всю эту инфу, если конечная задача добавить строчку из 2x id?
это просто view, представление одного из срезов - такая задача.
Последнее редактирование:
при чем здесь добавить в друзья?
Вопрос про чтение, а не про запись.
Вопрос в том, почему не не можем вытянуть имя, фамилию, никнейм, дату рождения и семейное положение кодом $userMapper->load($id);?
При том что та же доктрина без дополнительных плясок с бубном вытащит нам еще и города с языками.
Вурдалак
Продвинутый новичок
DataMapper можно использовать, но какой-то односторонний, другой, не тот, который работает с моделью для записи. Или вот AutoMapper, как тут упоминалось уже.
Суть не в том, чтобы вручную что-то там выбирать, а в том, что одна и та же модель не подходит.
Вурдалак
Продвинутый новичок
Да вопрос даже не в наборе свойств. Там могут быть очень похожие свойства, просто методы в принципе разные, семантика разная. А так часто бывает, что для чтения тоже одна модель, просто потому что лень там их как-то дробить.
а дальше, так как вся view у нас это json_serialize нужно конечно за(unset)ить ненужное
Ну блииин. Я именно же это и написал выше! Датамеппер заточенный под чтение для извлечения данных, на базе которого и генерится ридмодель. Рид модель вообще ничего не знает о базе и откуда эти данные пришли - максимум зависимость от датамеппера в фабрике или фабричных методах!
И как раз выше я и написал, что нет ни одного орм-а (и всего подобного), где была бы работа только на чтение. Все связанное с записью приходится выпиливать костылями
и датамеппер именно для удобного представления базы и ее сущностей и связей между сущностями базы, а не для представления доменной сущности (рид модели) или связей между ними.
нафига писать однотипные запросы там где можно обойтись короткими методами с минимальной возможностью допустить ошибку, да и код в разы поддерживаемый?
нафига писать однотипные запросы там где можно обойтись короткими методами с минимальной возможностью допустить ошибку, да и код в разы поддерживаемый?
И чтобы было понятно, я спросил только потому что было интересно как другие делают.
Но судя по комментариям нравится делать костыльно
Почему костыльно, потому что писать 100500 однотипных запросов, в которых легко допустить ошибку и нет нормального автокомплита, это костыль, который размазывается равномерно по всему коду.
Но и юзать существующие датамепперы с выпиливанием из них части связанной с записью - тоже костыль, но хотя бы костыль только в одном месте, а потом весь остальной код получается короче и читабельнее и поддерживаемее
Но судя по комментариям нравится делать костыльно
Почему костыльно, потому что писать 100500 однотипных запросов, в которых легко допустить ошибку и нет нормального автокомплита, это костыль, который размазывается равномерно по всему коду.
Но и юзать существующие датамепперы с выпиливанием из них части связанной с записью - тоже костыль, но хотя бы костыль только в одном месте, а потом весь остальной код получается короче и читабельнее и поддерживаемее
Если мы четко себе представляем архитектуру, то уж решить вопрос DRY - дело техники, для этого все есть (квери-билдеры, автомапперы и т.д.), это настолько очевидно, что неинтересно обсуждать.
А вот если понимать принцип DRY примитивно-механически, как повторение вроде бы одного и того же кода без учета контекста, то и появляются ложные абстракции, типа общей модели для Read&Write, общей валидации для application и domain, REST там, где речь не о state transfer и прочие уродцы.
но если бы было не интересно обсуждать, то и вопросов у @Фанат - а не возникло бы.
лично у меня вопрос, как с наименьшим количеством костылей получить данные для рид модели (данные а не саму модель - она вообще ничего не знает об источнике данных). И вот здесь получается все не так красиво - или только ручками запросы или используем датамепперы/тейблгейтвеи которые сильно заточены под запись и как результат свои нюансы - или править исходники под себя или смириться с нежданчиками из-за кода для записи.
Ну ты там утверждаешь, написал маппер, который возвращает профиль по ид
там ( фио, фото, статус пользователя, количество друзей ( тут вообще интересно, это еще особая модель типа sql-agregate) и тд) я языки на которых пользователь говорит не трогаю. Этот обьект профиля, который вернул нам $userMapper->load($id); который рид-модель Где будешь использовать еще?
В отличие от внутренностей write-моделей, read-модели в подавляющем большинстве случаев "плоские" (или коллекция "плоских").
Так что достаточно замапить полученный из dbal stdClass (или их массив) на read model (или их коллекцию) по каким-нибудь банальным правилам (типа, under_score to camelCase), с этим прекрасно справляются автомапперы.