Модели в фреймворках

Вурдалак

I'd like to model your domain
Подразумевается, что модель для записи обычно отличается от модели, которую используют для чтения. CQRS, вот это всё. Но если ты используешь сеттеры-геттеры и не видишь в этом проблемы, то забей, это всё течения западные, пытаются мозги запудрить русским.
 

Yoskaldyr

.
Партнер клуба
@Вурдалак Если отложить в сторону запись (вообще отложить). Для модели чтения как получать данные из базы для создания модели? Писать все прямыми запросами (или через квери билдер не принципиально) или использовать готовые методы data mapper-а (не обязательно один метод и не обязательно одного дата меппера)?
 

WMix

герр M:)ller
Партнер клуба
"все прямыми запросами (или через квери билдер не принципиально) " - получили некий array.. хочешь object? - мапь!
 

Yoskaldyr

.
Партнер клуба
"все прямыми запросами (или через квери билдер не принципиально) " - получили некий array...
А нафига??? Месье любитель писать тонны однотипного кода? Я понимаю что для некоторых случаев нужны прямые запросы, но всетаки в более половины случаев (а иногда и в более 90%) для получения данных, необходимых для модели достаточно простого вызова метода из репозитория/датамеппера/тейблгейтвея.

А если речь идет о зависимых данных + когда колонки перечисляемые, поддерживать эти зависимости сразу в нескольких местах напряжно. Основной косяк такого подхода что приходится полностью скрывать методы и функционал связанный с обновлением записей в датамеппере и часто это вообще не тривиально или не возможно без правки исходников. Сейчас нет вообще ни одного орм-а или датамеппера с возмоностью работать в отдельном режиме, заточенном под чтение с иммутабельными записями, всегда приходится костылить. Т.е. хорошо чтобы было единое описание схемы и связей как и для обычного датамеппера, так и для заточенного только под чтение, но такого нет :(
 

WMix

герр M:)ller
Партнер клуба

представь себе страничку (профиль пользователя), представь модель страницы.
представь команду "Добавить в друзья", осознай, что представленная модель для этой задачи не подходит

это разные модели, да можно вытянуть профиль, языки, колво друзей, ... и добавить метод "Добавить в друзья (ид)" только нафига тянуть всю эту инфу, если конечная задача добавить строчку из 2x id?

Месье любитель писать тонны однотипного кода?
это просто view, представление одного из срезов - такая задача.
 
Последнее редактирование:

Фанат

oncle terrible
Команда форума
представь команду "Добавить в друзья"
при чем здесь добавить в друзья?
Вопрос про чтение, а не про запись.

Вопрос в том, почему не не можем вытянуть имя, фамилию, никнейм, дату рождения и семейное положение кодом $userMapper->load($id);?
При том что та же доктрина без дополнительных плясок с бубном вытащит нам еще и города с языками.
 

Вурдалак

I'd like to model your domain
Для модели чтения как получать данные из базы для создания модели? Писать все прямыми запросами (или через квери билдер не принципиально) или использовать готовые методы data mapper-а (не обязательно один метод и не обязательно одного дата меппера)?
DataMapper можно использовать, но какой-то односторонний, другой, не тот, который работает с моделью для записи. Или вот AutoMapper, как тут упоминалось уже.

Суть не в том, чтобы вручную что-то там выбирать, а в том, что одна и та же модель не подходит.
 

WMix

герр M:)ller
Партнер клуба
$userMapper->load($id); тоже написан под конкретную view там нет к примеру статус="заблокирован". конечно можно
 

Вурдалак

I'd like to model your domain
$userMapper->load($id); тоже написан под конкретную view там нет к примеру статус="заблокирован". конечно можно
Да вопрос даже не в наборе свойств. Там могут быть очень похожие свойства, просто методы в принципе разные, семантика разная. А так часто бывает, что для чтения тоже одна модель, просто потому что лень там их как-то дробить.
 

Yoskaldyr

.
Партнер клуба
DataMapper можно использовать, но какой-то односторонний, другой, не тот, который работает с моделью для записи. Или вот AutoMapper, как тут упоминалось уже.
Ну блииин. Я именно же это и написал выше! Датамеппер заточенный под чтение для извлечения данных, на базе которого и генерится ридмодель. Рид модель вообще ничего не знает о базе и откуда эти данные пришли - максимум зависимость от датамеппера в фабрике или фабричных методах!
И как раз выше я и написал, что нет ни одного орм-а (и всего подобного), где была бы работа только на чтение. Все связанное с записью приходится выпиливать костылями
 
  • Like
Реакции: WMix

Yoskaldyr

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

Yoskaldyr

.
Партнер клуба
И чтобы было понятно, я спросил только потому что было интересно как другие делают.
Но судя по комментариям нравится делать костыльно
Почему костыльно, потому что писать 100500 однотипных запросов, в которых легко допустить ошибку и нет нормального автокомплита, это костыль, который размазывается равномерно по всему коду.
Но и юзать существующие датамепперы с выпиливанием из них части связанной с записью - тоже костыль, но хотя бы костыль только в одном месте, а потом весь остальной код получается короче и читабельнее и поддерживаемее
 

Yoskaldyr

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

fixxxer

К.О.
Партнер клуба
Почему костыльно, потому что писать 100500 однотипных запросов, в которых легко допустить ошибку и нет нормального автокомплита, это костыль, который размазывается равномерно по всему коду.
Если мы четко себе представляем архитектуру, то уж решить вопрос DRY - дело техники, для этого все есть (квери-билдеры, автомапперы и т.д.), это настолько очевидно, что неинтересно обсуждать.

А вот если понимать принцип DRY примитивно-механически, как повторение вроде бы одного и того же кода без учета контекста, то и появляются ложные абстракции, типа общей модели для Read&Write, общей валидации для application и domain, REST там, где речь не о state transfer и прочие уродцы.
 

Yoskaldyr

.
Партнер клуба
это настолько очевидно, что неинтересно обсуждать.
но если бы было не интересно обсуждать, то и вопросов у @Фанат - а не возникло бы.

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

WMix

герр M:)ller
Партнер клуба
А сколько раз эту рид-модель будешь использовать? Назови мне ситуацию когда тот же профиль для чтения используется дважды
 

Yoskaldyr

.
Партнер клуба
@WMix А где я писал что для чтения я буду использовать несколько раз???? И какое отношение это имеет к вопросу о данных для модели?
 

WMix

герр M:)ller
Партнер клуба
Ну ты там утверждаешь, написал маппер, который возвращает профиль по ид
Месье любитель писать тонны однотипного кода?
там ( фио, фото, статус пользователя, количество друзей ( тут вообще интересно, это еще особая модель типа sql-agregate) и тд) я языки на которых пользователь говорит не трогаю. Этот обьект профиля, который вернул нам $userMapper->load($id); который рид-модель Где будешь использовать еще?
 

fixxxer

К.О.
Партнер клуба
лично у меня вопрос, как с наименьшим количеством костылей получить данные для рид модели (данные а не саму модель - она вообще ничего не знает об источнике данных)
В отличие от внутренностей write-моделей, read-модели в подавляющем большинстве случаев "плоские" (или коллекция "плоских").
Так что достаточно замапить полученный из dbal stdClass (или их массив) на read model (или их коллекцию) по каким-нибудь банальным правилам (типа, under_score to camelCase), с этим прекрасно справляются автомапперы.
 
Сверху