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

блин, понимать бы по человечески как применять корректно DTO... :(

ну блин, как применять правильно

тебе нужна где-то какая-то структура данных, например элемент списка

пилишь класс

пилишь мэппер

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

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

и насколько это отразиться на скорости

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

это не сущность

это просто структура данных

модель, если я прав.

и насколько это отразиться на скорости

если паришься о скорости - то тогда как я сказал выше - DQL -> ArrayHydrator -> трансформации через какой fractal

модель, если я прав.

ты прав, это модель данных. По сути это некое представление данных. Без логики.

осталось понять представляет ли то что "это модель" хоть какую-нибудь ценность

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

у тебя есть объекты

DTO - это тупой объект для передачи состояния. он умеет хранить стэйт и все

больше ничего он уметь не должен

более того

есть такая штука как single responsibility

предположим у тебя есть объект User

и просто предположим что у него есть релейшен friends

Одну секунду только... что такое ArrayHydrator? O_o

Одну секунду только... что такое ArrayHydrator? O_o

ходи в доку по доктрине

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

сохраняя структуру и все такое

но не надо геттеры например писать

или "виртуальные поля"

ты просто берешь массивчик, загоняешь это в некий трансформер и получаешь ровно ту структуру которую хочешь

ооо, уже что-то начинает вырисовываться в логике

это то что я и ищу... на аналогию как работал с фракталом в ларке

так вот к вопросу о SRP

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

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

public function order(int $quantity): OrderLine { return new OriderLine($this->price, $this, $quantity); }

Но

у тебя ж еще есть задачи вроде "надо для UI списочек юзеро показать"

или "списочек продуктов"

или "надо списочек продуктов и сколько их покупали"

и если смотреть с позиции SRP - это разные зоны ответственности

пусть сущность отвечает только за операции записи

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

а логика UI и что где отображать - пусть кто-то другой этим будет заниматься

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

по хорошему

Чувак

А нах тебе дто если можешь массив вернуть?

А нах тебе дто если можешь массив вернуть?

у тебя в этом случае массив и будет DTO)

можно делать по жесткому с фиксированными структурами

Я ж о чём)

а я ленивая жопа и беру массивчики

Ну для сериалайзкра меньше проблем

Сразу в нормал виде будет

На шаг меньше

вот в целом это то что я и искал, если правильно помню - presenter-ы или четта такое было

Ну для сериалайзкра меньше проблем

ну а при моей схеме сериалайзер и не нужен

в сериалайзе не все выведешь

вот в целом это то что я и искал, если правильно помню - presenter-ы или четта такое было

да не презентеры это.... хотя хз

еще их респондерами бывают называют

это в ларке обзывалось кажись так

в ларке "презентеры" это раковая опухоль сверху актив рекорд модельки

Сережа, направление понял, спасибо, пойду ковырять в эту сторону... )

Ларка - это просто раковая выхухоль :)

Сережа, направление понял, спасибо, пойду ковырять в эту сторону... )

рекомендую еще покурить graphql

> Ларка - это просто раковая выхухоль :) да не, норм штука. Автор мудак а фреймворк норм.

@Enleur к слову ковыряю graphql - пока нравится

ERROR: S client not available

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

@Enleur к слову ковыряю graphql - пока нравится

норм с пыхом либы?

норм с пыхом либы?

нуууу.....

неудобно пока, но это может пока с непривычки

а что неудобно? (я вообще смотрел слишком мало)

пока основное неудобство с тем как ресолверы пишутся

не полностью пока разобрался как более оптимальный SQL генерить в зависимости от запросов

еще есть вопросы как правильно проектировать граф моделек

ну то есть потому хочу полноценную апку замутить

посмотреть покрутить

а как ограничения вешаешь?

чтоб никто одним запросом всю базу не грузил )

еще не вешаю пока)

добавил в список "разобраться"

@fes0r а можешь ткунь в доку доктрины по arrayhydrator? O_o в упор нихрена по этому не находится

единственное что нашел пока это: https://github.com/pmill/doctrine-array-hydrator

http://ocramius.github.io/blog/doctrine-orm-optimization-hydration/

вот можешь с этого начать

Пасиба. :)

http://ocramius.github.io/blog/doctrine-orm-optimization-hydration/

ушел курить

а вот в доке

это та же ссылка )

https://github.com/doctrine/doctrine2/blob/master/docs/en/reference/dql-doctrine-query-language.rst#query-result-formats

сорян

О! Пасиб )

@fes0r

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

там тебя забанили

ну и хуй с ними

короч

был у меня случай