и в целом проще взять готовый пакет какой (https://github.com/Ocramius/GeneratedHydrator)

и внутри репозитория гидрироать/дегидрировать сущности

любопытно

спасибо

а чем плох мой способ?

1. тупой бойлерплейт 2. сущность теперь знает как она сохраняется в базе

не знает

и почему в базе?

ничего про базу нету

сущность <репозиторий> мэппер

она знает как себя превратить в дто и обратно

почему это плохо?

проблема только в бойлерплейте

ничего про базу нету

где ты будешь \DateTime приводить к тому видк, в котором она будет в базе?

или Money какой

и что это прям в публичной зоне

или еще чего

гидрация обычно скрыта где-то глубоко

где ты будешь \DateTime приводить к тому видк, в котором она будет в базе?

это будет делать репозиторий

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

это будет делать репозиторий

а кто будет отвечать за связи?

какие связи?

связи между объектами

между сущностями

static function fromSaved(array $state) { $me = new self: $me->myProp = $state['prop']; return $me; }

Такой вопрос Я не особо шарю в бд пока У меня есть таблица с приложениями, и таблица downloads, при нажатии на donwload я пишу в таблицу downloads id юзера, id приложения и время Мне нужно выводить количество скачиваний для каждого приложения К примеру скачиваний 1000000 всего. И как лучше сделать: писать в таблицу downloads и добавить колонку count_downloads в таблицу с приложениями, и ее тоже при скачивании на 1 увеличивать, или все таки получать для приложения через select count(*) from downloads, и как это будет если на странице 50 приложений, получается 50 запросов при каждом обновлении страницы И вот только что подумал - нет возможности, чтобы сервер бд сам заполнял колонку count_downloads по id приложения?

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

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

ну с этим можно жить, хотя и очень неприятно)

ну с этим можно жить, хотя и очень неприятно)

да ну, вся красота теряется

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

нуу хз, если ты там сайд-эффектишь, от сам виноват

а если нет, то потом стейт перетрется

так что)

я в конструкторе много чего могу делать

выставлять начальный стэйт сущности например

ну так потом перетрется ж

стейтом из базы

ну тут уже бойлерплейт

да, это есть)

короч гидраторы

и не париться

одобряю

Я вообще вас не понимаю((

@nicecoder пиши процедурки/тригера. Ну или в коде тупо инкремент поля делай

последнее лучше

То есть это норм? 2 запроса будет Я просто почему то реально думал, что сервер может сам заполнять эту колонку для каждого приложения количеством скачиваний по id приложения

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

почему больше одного раза?

почему больше одного раза?

на каждый fromState

будет дергаться конструктор

при этом объект на самом деле не умирал

при этом объект на самом деле не умирал

объекта нет

это пыхо-проблемы

это статик метод

объект умирает когда удаляется из базы

ах это

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

понял

создание = конструктор, удаление = деструктор

на создание может вешаться какое-то хитрое поле

и как же гидратор эту проблему решит?

class A extends YourClass { public function __constructor() { } }

вуаля

вообще-то намного проще

ну там рефлексии всякие, но это лобовой вариант

$reflection = new \ReflectionClass(User::class); $user = $reflection->newInstanceWithoutConstructor();

это для слабаков

понял

ERROR: S client not available

это для слабаков

flnal class User

я сломал твой способ

?

а в случае с гидратором кто отвечает за связи?

не ну понятно что доктринка тож сломается

а в случае с гидратором кто отвечает за связи?

посмотри на доктрину) там за это отвечает штука имплементящая Collection

ну то есть...

$this->friends->add($user);

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

есть ж обратные

или если ты попросил - запомнит что надо в базу сохранить например

там тогда просто поле

ну вот тут уже unit of work

делает diff

ну то есть тут уже просто сэтится значение гидратором

или достается

а что с ним делать решают другие штуки

да, строит граф, потом по нему поиском в глубину строит последовательность и ее дергает

дерг дерг

? спасибо

@f3ath короч если ты вдруг вздумал написать свою ORM - это сложно и надолго

и не получится

протечет

протечет

ничего страшного

я хочу понять, почему не стоит писать свою ОРМ не пытаясь ее реально написать

ничего страшного

те, кто хотят написать обычно хотят не этого)

я хочу понять, почему не стоит писать свою ОРМ не пытаясь ее реально написать

почитай исходники доктрины) или какой нибудь atlas/orm

я хочу понять, почему не стоит писать свою ОРМ не пытаясь ее реально написать

так, для непросвященных(меня), а какие причины ее писать?

ну причина обычно такая "ууу, лень разбираться, нафигачу свой костыль"

ы

потом костыль оборачивается проблемами

хочется знать, какими именно