если ты выбираешь между "анемичной моделью" (вся проблема которой что ей нужна та же инфраструктура что и для нормальной но ты ее "бесплатно" получаешь с доктриной а значит похеру) и "хуево разбитыми сущностями с логикой" с первым будет куда меньше проблем. Более того, если ты оказался в ситуации когда у тебя логика в сущностях и сущности эти на 1000+ строк кода, то адекватной стратегией по перераспределению логики вполне может быть откат к анемичной модели и потом оттуда уже проще будет "нарезать" стэйт.

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

не, просто "логика в сущностях" без разбиения стэйта может породить куда более жесткие формы связанности и "нарезать стэйт" так просто не выйдет.

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

но этот "откат" - это должно быть осознанное решение, в котором есть осознание проблемы, цели этого отката, мотивы и вообще перспектива

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

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

Анемичная модель вполне себе допустима для mvp, когда нужно что-то сваять "на коленке" максимально быстро и ещё толком непонятны бизнес требования да и в целом перспективы, или же с внешней стейт-машиной. В остальных же случаях при развитии проекта и увеличении бизнес логики боязнь "проблемы большой модели" перерастает в "проблему большого количества мест контроля", что в конце концов приводит к неизбежному появлению невалидных состояний.

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

Оправдывает, если разбивать стэйт. У меня под руками пример сущности на 4к строк который очень сложно дробить, что занятно, если разбить его на 4-5 агрегатов то кода будет где-то в полтора раза меньше.

Анемия это потенциально патологический каплинг ну или глобальный каплинг в лучшем случае. Если же ты анемию закрываешь сервисами так что к сущностям просто так не подобраться то в целом контроль тот же, примерно, просто тестить такое обычно сложнее.

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

Если анемия снаружи полностью закрыта и к ней не подобраться, то тут практически стейт-машина и получается. Использование может быть вполне безопасным. Но вот только остаётся вопрос "неприкосновенности" такой модели с течением времени.

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

Товарищи, помогите, сейчас мозгом потеку. Вот такое правило валидации для поля:

 /**
  * @Assert\Regex("/^[a-zA-Zа-яА-Я\-\_]+$/")
  */
 private $nickname;


Не пропускает некоторые буквы. В частности ф, ц, у

Как это, почему?

Другие русские буквы пропускает нормально

Не в тему, там ещё надо ё добавить:)

И можно писать А-яA-z

Попробовал. Вот такое выдает

Warning: preg_match(): Compilation failed: range out of order in character class at offset 124

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

@Assert\Regex("/^[йцукенгшщзхЙЦУКЕНГШЩЗХфывапролджФЫВАПРОЛДЖячсмитьбюЯЧСМИТЬБЮa-zA-Z\-\_]+$/")

потому что в таблице символов ASCII они находятся дальше