Alice юзал, очень даже ок кстати

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

alice говно

юзлес элис

А что лучше? Цель: в кратчайшие сроки набутстрапить из имеющихся данных фикстур, чтобы проект можно было собирать и прогонять хотя бы базовые функциональные тесты. Потому, что сейчас проект надо разворачивать вручную и заливать дамп БД.

doctrine/data fixtures + faker

я лично на этом варианте остановился

+ частенько реюзаю сервисы в фикстурах

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

doctrine/data fixtures + faker

Спасибо. Посмотрю. Хотя, насколько я понял, Alice тоже использует faker. Но, в общем, погляжу тогда более низкоуровневый вариант тоже и буду думать.

alice провацирует тебя делать фикстуры именно данных, то есть пихает данные в сущности и все

это норм для очень простых ситуаций, но как бы есть отдельно doctrine faker populator

или как-то так

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

data-fixtures в этом ключе как-то гибче

позволяет тебе делать то же что и alice

но можно много больше и много веселее

data-fixtures в этом ключе как-то гибче

Я понимаю :) Но там логику работы писать надо :)

эм... логику работы?

отныне @fes0r с правами админа, а флуд он не любит.. поэтому не злите его ?

ну ладно)

ты кстати за что голосовал? save/remove ок?

не знаю о чем ты)

save/update/remove в репозитории доктрины Да это ок – 7 ??????? 58% Нет это плохо – 5 ????? 42% ? 12 people voted so far.

за это

remove - норм, save/update - не норм

ну и remove только если название подходит

инога это archivate или еще чего

у меня remove в репосах есть, но это один репос из 5-ти

а может даже реже

у нас этих методов не было вот до мержа который сегодня сделали, после этого начался холивар и я его сюда перенес) сам я считал что эти методы не айс

а щас вот изменил точку зрения и считаю что это ок

если честь ограничение по типу

у нас этих методов не было вот до мержа который сегодня сделали, после этого начался холивар и я его сюда перенес) сам я считал что эти методы не айс

мерджа в смысле на твоем проекте?

да

save/update не ок

инога это archivate или еще чего

почему не $entity->archivate()

?

почему не $entity->archivate()

ну в целом да, так может лучше

если честь ограничение по типу

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

да, так определенно лучше

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

у меня везде тайп хинты

почему не $entity->archivate()

UserRepository::archivate($entity) в таком случае

сущность себя ж в инфраструктуре не сможет обновить

если это не ларавель

?

блин я плыву уже

UserRepository::archivate($entity) в таком случае

так я не понял, ты за save/update?

просто....

если мыслить с точки зрения хранилища... сущность о хранилище не знает

мы ее просто храним на полке

но мы можем вынуть с полки сущность

а потому remove должен остаться

нет, но полка знает о книге

полка знает о книге только факт ее наличия

по сути

тогда book->archivate() неправильно, если при архивировании книга перемещается с полки в архив

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

ну в целом да

$books->take($book); $archive->put($book);

перемещение сущности из одного репозитория в другой

единственное что

возможно $achive зависимость $books

и тогда $books можно попросить перевести книгу в архив

либо нам нужен какой-то сервис архиватор

да, тогда books - не полка

$books->take($book); $archive->put($book);

тогда take должен и remove сразу делать внутри

да, тогда books - не полка

почему?

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

полка знает об архиве?

которая автоматически складывает в архив все старые книги

а архив это коробка под полкой

я бы так всё равно никогда не делал

пока не вижу в этом смысла

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

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

например

хотя тут можно сделать склад как сущность

раз уж ему надо между другими складами трансферить что-то

для одной сущности - один репозиторий - вот!

для одной сущности - один репозиторий - вот!

один репозиторий на корень агрегата

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

да)

погорячился

ну я делал штуку, которая сущности сохраняла в redis, доставала по id, делала поиск по проиндексированным полям, я назвал это репозиторием, и там был метод save

т.к. unitofwork я не реализовывал

и что это плохо иметь в такой реализации save?

или это не репозиторий?)

это больше похоже на table gateway или dao

просто другое название

настоящий репозиторий внутри использовал бы тот самый dao/gateway + uow

то есть репозиторий обязан вести себя как коллекция

и нет persistence-oriented repository

или как там

да

потому что репозиторий не отвечает за персист

он делигирует его гейтвэю

репозиторий это красивая идея, позволяющая полностью скрыть хранилище

как деталь реализации