не, никаких геттеров

это запрос по сути к бд

это запрос по сути к бд

не надо мне запросов к бд

просто класс и публичные проперти

я имею ввижду иметь метод по сборке обычного активрекордного обхекта

хотя я могу запилить ленивую инициализацию коллекций

я имею ввижду иметь метод по сборке обычного активрекордного обхекта

он не эктив

повторяю

пассивная запись

ты про впринципе или про частный случай?

ты решаешь задачу экономии памяти?

основная цель - полностью разделить код для записи и чтения и избавиться от ненужных геттеров

экономия памяти, производительность и т.д. - это побочные эффекты

основная цель - разделить код и сделать работу с этим делом удобной

что бы я мог для простого списка сделать что-то типа SELECT u FROM users WHERE id=1 и закинуть сразу в json encode

основная цель - полностью разделить код для записи и чтения и избавиться от ненужных геттеров

опаньки

но это же.. лищние расходы

если потребуется и то и то

но это же.. лищние расходы

где ты их нашел то?

если потребуется и то и то

то это будет значить что у тебя с кодом что-то не так

ну для расстранички можно ограничится, условно, стдклассом с raw запроса )

ай короч забей

ты делаешь предположение что "код говно, как же быть", а у меня говно только в том что приходится геттеры держать

CQS короч

основная цель - разделить код и сделать работу с этим делом удобной

разделять что-то на чтение и запист не вяжется с удобством для программиста..

разделять что-то на чтение и запист не вяжется с удобством для программиста..

ты просто видимо слишком примитивно это разделение видишь

перефразирую - "операции обработки данных" и "операции отображения этих данных"

у тебя они по хорошему никогда не пересекаются

ты просто видимо слишком примитивно это разделение видишь

забавно что ты исходишь из ошибочных предположений :)

перефразирую - "операции обработки данных" и "операции отображения этих данных"

я так и понял

ну и где тут "неудобство", где тут лишние расходы?

но нода-то больше придётся обслуживать

как раз наоборот. По моим прикидкам кода существенно меньше выходит и код сам по себе упрощается

ты имеешь ввиду экономия так как самогенерируемое а либа как бы не считается, если её зарелизить и она работает?

ты имеешь ввиду экономия так как самогенерируемое а либа как бы не считается, если её зарелизить и она работает?

а ты учитываешь фреймворк например?)

ну вот я про то же

ну либа простая довольно

так-то всё можно вынести )

я бы даже сказал примитивная

а упрощение больше за счет более четкого разделения ответственности, это позволяет проще вносить изменения

и больш контроля

типа следующий уровень это уже полноценный CQRS

но с этим в php плохо

если она позволила бы решать проблемы не с тупо маппингом а с чем-то большим, например с джоинами или комбайном на серию запросов - даже полезно было бы

т.е. денормализовывать данные

если она позволила бы решать проблемы не с тупо маппингом а с чем-то большим, например с джоинами или комбайном на серию запросов - даже полезно было бы

1. джойны поддерживаются 2. у меня есть batch подгрузка ресурсов что бы склеивать выборки на стороне приложения и не форсить связанность разных модулей

как раз типичная страница "с контентом+джоины"

т.е. денормализовывать данные

"нормализовывать".

ну короч... я не понял что за проблемы с джойнами у тебя

я повторюсь - любой запрос который тебе может доктрина замэпить на сущности я смогу замэпить на dto

с джойнами, подзапросами, как хочешь

наоборот же ДЕ

:)

но это не повод для разных контекстов создавать неявную связанность на уровне базы, для этой проблемы у меня как раз таки есть batch load данных

или всётаки ->get

с гет даже круче

наоборот же ДЕ

у тебя результат любого sql запроса денормализованное представление данных. Далее ты просто их мэпишь

с гет даже круче

чем интересно

если на этапе формирования запроса можно определить что можно на подуровнях подтягивать а не тупо копировать

если на этапе формирования запроса можно определить что можно на подуровнях подтягивать а не тупо копировать

о чем ты вообще?

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

условно $user->country->name $userDTO->countryDTO->name подразумевает нормализацию+ссылки. по сути геттер. но можно конечно и тяп ляп $userDTO->country_name денормализация с прописанными полями $userDTO->country['name'] денормализация "полная"

> $userDTO->countryDTO->name почему у тебя имя класса просочилось в название поле? с какого перепуга оно меняется?

и в 1 и 3 варианте можно сделать только id+name

> $userDTO->countryDTO->name почему у тебя имя класса просочилось в название поле? с какого перепуга оно меняется?

я показал что там лежит

> $userDTO->country_name нет уж, пусть будет объект. Так расширяемее

я бы сделал ->getCountry()

ЗАЧЕМ!

ERROR: S client not available

чем getCountry() отличается от ->country

и почему у тебя в country массив

почему я туда добавил словло ДТО скорее

потому что там дто а не модель

дто не массив

это такой же класс с абсолютно такой же структурой полей (в моем случае)

я бы сделал ->getCountry()

а это спорно да

дто не массив

я под массивом имел ввиду стдкласс

....никаких std классов

все с четко определенными типами

а последний пример был просто вариативность на тему

короч проехали

так в данном случае я это и имел ввиду

хрень какая-то

нифига не понимаю что ты хочешь донести

пойду спать

очевидно никто не будет делать UserDTO который стдкласс без описаний

->get просто чтобы показать что этих данных там может не быть(лезилоад)

->get просто чтобы показать что этих данных там может не быть(лезилоад)

хирли их там не будет?)

ооп же

да и зачем мне это показывать (прокси-классы ты можешь заюзать)

расширяемость

ооп же

ООП как раз таки для того что бы СКРЫВАТЬ а не показывать там что-то о внутреннем устройстве

расширяемость

это не то место где надо расширять

геттеры - не нужны

в контексте DTO уж точно

с точки зрения ооп - да не нужны

но я про вариативность связанных полей в других таблицах

но если делать чёттипа $userQuery = UserQuery::where()->with(Country::class ); $userDTO = UserDAO::getDTO($query); $userDTO->name; $countryDTO = $userDTO->country; как-то так

осторожно жирная модель

но если делать чёттипа $userQuery = UserQuery::where()->with(Country::class ); $userDTO = UserDAO::getDTO($query); $userDTO->name; $countryDTO = $userDTO->country; как-то так

у тебя есть типы, и есть nullable типы, чем тебе тут геттеры помогут то?

насколько я понял ты пытаешься закрыть геттерами дырки с null-safety