Рома
в лaре было через create вот и написал так, чтоб сразу обновлял
Михаил
нет - flush это аналог save
А точнее "Просчитай все изменения которые произошли и отправь их в бд одной транзакцией"
Рома
пхаха код на ларе
public function createFromArray(array $data): Stmt
{
return Stmt::query()->create($data);
}
/**
* Обновление из массива.
*
* @throws QueryException
*/
public function updateFromArray(Stmt $stmt, array $data): Stmt
{
$stmt->update($data);
return $stmt;
}
Михаил
persist - это способ попросить UnitOfWork учесть эту сущность. Ввести её в сделку
Михаил
пхаха код на ларе
public function createFromArray(array $data): Stmt
{
return Stmt::query()->create($data);
}
/**
* Обновление из массива.
*
* @throws QueryException
*/
public function updateFromArray(Stmt $stmt, array $data): Stmt
{
$stmt->update($data);
return $stmt;
}
Пхаха, дёргать бд на каждый чих
Рома
да на с# подобное есть entity framework вот с ним я работал) тоже самое
Павел
пхаха код на ларе
public function createFromArray(array $data): Stmt
{
return Stmt::query()->create($data);
}
/**
* Обновление из массива.
*
* @throws QueryException
*/
public function updateFromArray(Stmt $stmt, array $data): Stmt
{
$stmt->update($data);
return $stmt;
}
Не нужно сравнивать объёмы. Лара про скорость и магию, что ускоряет разработку в начале и замедляет и даёт баги в конце.
Симфони про очевидность и жёсткость, что даёт больше кода но и больше стабильности
Михаил
Не нужно сравнивать объёмы. Лара про скорость и магию, что ускоряет разработку в начале и замедляет и даёт баги в конце.
Симфони про очевидность и жёсткость, что даёт больше кода но и больше стабильности
Думать о ActiveRecord после UnitOfWork - это что-то из разряда фантастики
Павел
/**
* Обновление из массива.
*/
public function updateFromArray(Stmt $stmt, array $data): Stmt
{
$stmt->setName($data['name'])
->setEmail($data['email'])
->setMessage($data['message'])
->setComment($data['comment'])
->setStatus($data['status'])
->setUpdatedAt(Carbon::now()->toDateTimeImmutable())
;
$this->manager->persist($stmt);
$this->manager->flush();
return $stmt;
}
всё равно здесь не пройдут лишние поля
Нужна магия, посмотрите сериалайзер а в частности object to populate.
Это не симфони стайл. Но это будет замена update from array в 1 строку
Павел
Это из раздела плохих советов, но рабочих в стиле лары)
Рома
Serializer используются везде
Рома
и в django и в fast api
Рома
и на C#
Рома
ок спасибо изучу
Павел
Можно массив намапить на сущность в 1 строку
Рома
https://symfony.com/doc/current/components/serializer.html
Рома
это?
Павел
https://symfony.com/doc/current/components/serializer.html
Компонент этот, но дока мб не та, несколько страниц есть
Павел
Да, там есть о чем я говорил
Рома
да не это все равно лишняя нагрузка на код, нет простой реализации
Рома
пока через сетеры сделаю)
Михаил
пхаха код на ларе
public function createFromArray(array $data): Stmt
{
return Stmt::query()->create($data);
}
/**
* Обновление из массива.
*
* @throws QueryException
*/
public function updateFromArray(Stmt $stmt, array $data): Stmt
{
$stmt->update($data);
return $stmt;
}
Так на симфе было бы также только короче
#[Route(path: '/api/stmts/{id}', methods: ['put'])]
public function update(string $id, UpdateStmtDTO $dto, StmtRepository $stmts): Response
{
$stmt = $stmts->findById($id);
$stmt->updateAll($dto->toUpdateAllContext());
$stmt->stmts->add($stmt, flush: true);
return $this->json(['data' => $stmt]);
}
Рома
updateAll нет такого метода
Михаил
UpdateStmtDTO делаешь через ArgumentResolver
или вроде в 7 симфе есть маппер уже
@dexplon есть же?
Павел
UpdateStmtDTO делаешь через ArgumentResolver
или вроде в 7 симфе есть маппер уже
@dexplon есть же?
В 7 (или в 6.4 даже есть не помню) есть из коробки, до - можно такой самому написать
Михаил
В 7 (или в 6.4 даже есть не помню) есть из коробки, до - можно такой самому написать
а как он называется?
Рома
для чего писать все через get и set где то это имеет смысл, но тут в модели
Михаил
А, вот как
https://symfony.com/blog/new-in-symfony-6-3-mapping-request-data-to-typed-objects
Павел
Так на симфе было бы также только короче
#[Route(path: '/api/stmts/{id}', methods: ['put'])]
public function update(string $id, UpdateStmtDTO $dto, StmtRepository $stmts): Response
{
$stmt = $stmts->findById($id);
$stmt->updateAll($dto->toUpdateAllContext());
$stmt->stmts->add($stmt, flush: true);
return $this->json(['data' => $stmt]);
}
Но код мало имеет смысла, передавать массив в сущность имея дто, вся жёсткость пропадает.
Михаил
Но код мало имеет смысла, передавать массив в сущность имея дто, вся жёсткость пропадает.
А я где-то передавал массив в сущность?
Павел
from Array внутри сушности модели плохо.
Рома
он не сработает класс защещенный
Михаил
Нет, ты можешь конечно её под интерфейс положить
Михаил
но пихать в доменную сущность инфраструктурный дто - странно
Михаил
Но я согласен, время жизни dto становится очень маленьким, буквально 1 строчка. Я пока не решил эту проблему
Рома
в чем преимущества симфони? кроме того что один блогер сказа в актив рекорд можно хранить бизнес логику, хотя так уже сейчас не делают
Рома
я и в entity записал пару констант)
Рома
мне единсвенное нравится что маршруты пишут полностью и они читаемы и сразу привязаны к методу
в ларе пока найдешь этот маршрут по группам, префиксам, посмотришь из 100 имеющихся что подходит
Михаил
Выглядит странно и неправильно , но спорить не буду
Но смысл в том что у меня не анемичные сущности с геттерами и сеттерами а набор методов по её обновления и геттеры
User::create($createContext);
User::requestPasswordChange($passwordChangeContext)
User::updateBio($updateBioContext)
Сама сущность и вот эти контексты хранятся в доменке.
В итоге даже если я без юз-кейса дёргаю сущность - то у меня всё чистенько.
А дто нужна чтобы принять в себя реквест, провалидировать (косвенно) и трансформировать в доменный контекст для обновления сущности.
Павел
в чем преимущества симфони? кроме того что один блогер сказа в актив рекорд можно хранить бизнес логику, хотя так уже сейчас не делают
Делают, это тру стайл. Но начнётся холивар, я пасс.
Ар хуже тем что ходит сама в бд.
Чистые сущности в симфони , а в ар сплошная магия.
Di сильнее у симфы. Мессенджер очень интересный.
Лара использует много компонентов симфони, а не наоборот.
Опять же в Ларе проще гавнять
Павел
Верю что в Ларе можно написать хороший код ( многие не верят). Но делают это в процентном соотношении в симфони больше и чаще
Павел
Лара очень интересная для быстрой разработки особенно если использовать серверный фронт.
Рома
да сейчас симфони похож на лару с бандлами и прочими улучшениями, раньше это вообще был кошмар, собирать вручную и настраивать этот конструктор. Не сложнее лары, кода больше и рутины
Павел
Даже если взять ваши примеры, и что вы пытаетесь как в Ларе, то в Ларе можно лучше. Т.е. И в Ларе вы писали на скорость а не на жёсткость и качество.
Это не хорошо или плохо, это "другое"
Рома
так как принято было на работе
хотя бы архитектура была)
а на моем прошлом месте все в контролеры писали модели по 2000 строк ) и sql чистые
Dmitriy
Если на ларе писать хороший код, то нафига тогда она нужна
Павел
Если на ларе писать хороший код, то нафига тогда она нужна
Тоже верно. Поэтому надо использовать фреймворк так как он предполагает свое использование
Михаил
так как принято было на работе
хотя бы архитектура была)
а на моем прошлом месте все в контролеры писали модели по 2000 строк ) и sql чистые
о, узнаю ларку. Правда я видел по другому
1 (ОДНААААААА) строчка в контроллере
и ТУАЛЕТНАЯ БУМАГА на 200 строчке в сервисе
Михаил
зато не тупой толстый контроллер
Михаил
Или вообще шиза когда вызовы писали прям в роутере
Рома
да и методы по 100+ строк
Михаил
Или когда делали объекты ресурсов и внутри них бизнес логика
Михаил
ну и да, отдельный челендж собрать всю бизнес логику воедино
Павел
о, узнаю ларку. Правда я видел по другому
1 (ОДНААААААА) строчка в контроллере
и ТУАЛЕТНАЯ БУМАГА на 200 строчке в сервисе
Ну в симфе в контроллере не многим больше, если выделять апликейшен слой, ну или через шину(бас) работать
Павел
Скорее это уже вопрос не к ларе а к программистам
Павел
Если использовать анемик, то в симфони тоже всё в сервисах
Павел
Просто сделать толстую сущность в ларе проблемно как раз из-за АР
Nikolay
Дто создаёт другой объект?
Уже тысячу раз обсужадли. DTO может делать все что угодно. Ее основная задача быть сериализуемой и десереализуемой. Если добавить в нее метод Parse и возвращать нужный объект из нее, ничего страшного не происходит. Можно сказать, что принцип единой ответственности нарушается, но это уже перегиб
Nikolay
Просто кто-то один сказал, что нельзя. Я такое точно у Елисеева слышал и все подхватили
Nikolay
#[Route(path: '/api/stmts/{id}', methods: ['put'])]
public function update(Request $request, Stmt $id): Response
{
return $this->json($this->service->update($id, $request->toArray()));
}
сработает?
Это ужасные вопросы. Кажется, что вы не хотите фреймворк изучать
Nikolay
Это вторая или третья страница документации Routing
Павел
Уже тысячу раз обсужадли. DTO может делать все что угодно. Ее основная задача быть сериализуемой и десереализуемой. Если добавить в нее метод Parse и возвращать нужный объект из нее, ничего страшного не происходит. Можно сказать, что принцип единой ответственности нарушается, но это уже перегиб
Можете тысячу раз обсуждать и принимать для себя какое то решение.
ДТО - это тупой объект без логики (объект передачи данных между слоями в каноне). Ок приму, что можно в него напихать логику для его сбора и экстракте, тип что классы фабрик и сериализаторов не плодить.
Все что более - явный антипаттерн, или не дто
Михаил
Ну в симфе в контроллере не многим больше, если выделять апликейшен слой, ну или через шину(бас) работать
та это понятно. Просто в симфе из-за того что не принято прятать логику обыноч идёт так (это всепдокод, не ищите смысла)
pubf asdasd(Request $request, Service $serivice, Presenter $presenter) {
$context = Dto::fromRequest($reques->toArray());
$result = $service->toSmtng($context);
return $presenter->asResponse($result);
}
И пихаить всё это в сервисы или непонятно куда, я считаю - грех
ВСЁ!!
Nikolay
Можете тысячу раз обсуждать и принимать для себя какое то решение.
ДТО - это тупой объект без логики (объект передачи данных между слоями в каноне). Ок приму, что можно в него напихать логику для его сбора и экстракте, тип что классы фабрик и сериализаторов не плодить.
Все что более - явный антипаттерн, или не дто
Пожалуйста закон покажите, где это высечено в камне?:) Если я переименую просто DTO в Modal концептуально что то изменится?
Павел
Nikolay
В той же симфони сейчас Dto используют в параметрах метода контроллера и валидируют. Но как же получается - антипаттерн?
Павел
Пожалуйста закон покажите, где это высечено в камне?:) Если я переименую просто DTO в Modal концептуально что то изменится?
Открываете статьи что такое дто и смотрите
Павел
Ну вот мы пишем вот так
Nikolay
https://symfony.com/blog/new-in-symfony-6-3-mapping-request-data-to-typed-objects
Nikolay
Ну вот же
Nikolay
Правила валидации внутри DTO