Параллельно с этим стоит менять json_encode и сборку через constructor(args…) на сериалайзер, а чтобы он понимал что собирает, сделать инстансы сериалайзеров и нормалайзеров для каждого вида справочника. (может быть и фабрику получающую нужный тип).

У нас уже есть ViewModel и ViewTransformer, так что хранить доменные справочники и справочники представления вполне можно. Не решена главная проблема, в сущности справочник хранится как в БД, в видже своего id. И по нему собрать сразу его объект мы не можем. Так что здесь мы продолжаем раздумвать над вариантами.

• сущность хранит и примитив из бд, и объект формирующийся в геттере на лету.
• база хранит id вида <suffix>-<id> трансформер полечает проект, из него справочники и создает объект справочника.

https://www.doctrine-project.org/projects/doctrine-orm/en/3.3/reference/typedfieldmapper.html#implementing-a-typedfieldmapper вот правильная ссылка

(https://www.doctrine-project.org/projects/doctrine-orm/en/3.3/reference/typedfieldmapper.html#implementing-a-typedfieldmapper)[https://www.doctrine-project.org/projects/doctrine-orm/en/3.3/reference/typedfieldmapper.html#implementing-a-typedfieldmapper) кастомный FieldMapper может быть умеет больше, чем doctrineType

У нас факичски готова tndt-196, а значит можно сразу подумать над кешированием справочников.

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

В таком виде сделать задачу можно, но уже не очень хочется. Насколько оно сейчас необзодимо? Тут проблема наверное прежде всего в том, что элемент справочника сейчас не обладает собственой логикой, скорее отдает информацию о том, как себя отображать, поэтому на уровне домена и не особо используется. Но в будущем все равно надо будет на них переходить.

Итак предварительно вариант с хранением в сущности и примитивного значения для доктрины и реального объекта для остальных - вполне работает. Надо бы еще сет так же провернуть.

Вопрос только что мы от этого выигрываем, а что проигрываем.

Варианты:

• отказаться от type, и делать через двойной атрибут. один примитивный для хранения в доктрине, второй для хранения между get/set собранный на основе.
• некрасиво, но некрасивость в целом спрятана в анемичной модели
• хранить вместе с значением, суффикс проекта. тип можно определить по тому, какой Type вызван.
  • но это дикая дедупликация, плюс искать и сортировать по такому полю дороже.

DoctrineType получает на вход примитив с бд. При этом он не знает к какой сущности он относится, а потому не может по числу восстановить справочник. И в целом это логично, ведь его могут вызвать и в запросе на конкретное поле, когда вобще не известно из какого объекта оно получено.

Кажется это то же весьма актуально для работы над tndt-19

Через типы данных справочников, модель должна себе разворачивать объект справочника. Объект должен быть четко разделен на не заполненный, заполненный не тем, заполненный корректно, и отдавать это как в виде флагов, так и текстом в презентацию. В будущем, после tndt-85, мы просто уберем тексты отсуттвующего или неправильного справочника вынесем в презентацию, но объект всеравно будет иметь свой статус.

несколько связана с tndt-164, но здесь скорее вопросы их получения, заполнения и хранения в моделях. А там, содержимое одного из типов справочника

чтобы разгрузить fetcher надо, чтобы атрибуты сущностей могли сами себя заполнять бизнес-моделькой. Так что тут придется завести DoctrineType на каждый такой справочник, чтобы в сущности уже лежали DicitonaryItem вместо int’ов. Тогда они на 80% вопросов ответят сами без fetcher. Правда будет еще вопросы, вида дай мне все доступные значения справочника, но тут пусть делают $entity->getProject()->getTaskSettings()->get…()

Так же потихоньку разгружаем fetcher, оставляя его только для необычных странных случаев. Здесь же как минимум работы со справочниками в сущности переносим на doctrineType, чтобы их объекты сразу гидрировались в сущность.

Думается будет сделана в рамках tndt-85

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

Так что давайте перенесем обратно в сервисы, объекты в Model/Dicitionaries Settings в Model/Project/TaskSettings. А в services.yml удалим exclude и каждую диреткорию src/<что-то> будем делать сервисами отдельно.

Все идет к тому, что у нас плодятся несервисные или специализированные директории, все сервисы возвращться в сервисы. При отделении полноценного presentation еще и структура Services похудеет и станет более строгой. Думаю в неё надо переложить и Dicitionaries и Security.

Врядли мы дойдем до DDD, но гексагональную архитектуру мы все же начнем привносить. В её рамках Dictionary/Stylizer явно место в презентации Баджи задач либо переносятся в презентацию целиком, либо сервис баджей создает сами объекты, а превращение их в html задача презентаци