Этап
Открыта
Тип
Рефакторнинг
Приоритет
Обычный
Трудоемкость
Обычная
Создана
Дата создания
4 года назад
Назначена
Обновлена
год и 4 месяца назад

Проект эта штука, которая нужна у нас всем. Чтобы не собирать в одном ProjectService всю работу всех, мы её разнесем по сервисам.

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

Registry это просто обертка над кешем. (И кстати это повод сразу добавить в проект redis tndt-196)

Подробности систем в Получение связанной с проектом инфы (полномочий, справочников, и т.д.)

В рамках tndt-4 мы сделали очень простую и не оптимальную реализацию кеширования проектов для DictionaryService. В рамках этой задачи хорошо бы её рассмотреть и переделать нормально, даже если по итогу ProjectRegistrry вводить не будем. (можно, например, выделить её в отдельную задачу если эта задача не будет решаться)

Панель управления

Комментарии могут оставлять только авторизованные пользователи
 demius год и 4 месяца назад

Вобще говоря, с наличием redis, эта задача сводится к заведения в репозитории или в спецификации метода получения проекта по suffix и храннею в кеше. (а так же умении его оттуда выкидывать). при чем изменение даты и прочей мелочи в целом может и не выкидывать, главное чтобы другие методы хранящие проект в UoW не забрали закешированную версию. так тчо может вариант с отдельным Registry или Storage и не столь уж и глуп.

 demius 2 года назад

Прежде чем делать кеш именно проектов, необзодимо включить общий кеш запросов доктрины и посмотреть а надо ли нам вобще кешировать проекты, или они и так всегда есть.

 demius 3 года назад

Сильно связана с tndt-108. Если там мы решим делать TaskSettingsService, то он может опционально посмотреть здесь, если там перейдем на Model/Project это будет репозиторий именно моделей, а не сущностей. (А сущности будут кешироваться в рамках кеша доктрины)

 demius 3 года назад

Кроме того у нас вполне могут быть разные бизнес-модели на одну сущность. Проект для системы полномочий(с ролями и юзерами), проект для задач и документов (с справочниками), проект со своей статистикой. Они все должны браться из сущностей (которые кеширует доктрина) и кешировать свои модели со своими стратегиями сброса, чтобы полномочия не перестраивались, когда пм меняет справочник

 demius 3 года назад

И спецификации, как реализация бизнес-логики выборки моделей должна по идее выбирать именно модели из этого регистри, а не сущности, и вобще не знать о join

 demius 3 года назад

Если перейдем ссущностей на модели, этотт регистри должен кешировать именно модели, сущности уже кеширует доктрина.

 demius 3 года назад

В процессе переделки на спецификации с одной стороны логика контроллеров стала сильно проще, прямо скажем стала элементарной, что плюс. Минус эта крутая и мощная VisibleByUserSpec добавляет в запрос join на projectUsers, причем для 95% вызовов join для поиска полномочий текущего пользователя.

В этой задаче стоит подумать над оптимизации этой спецификации.

  • Либо добавить VisibleByCurrentUser, являющейся сервисом, лезущим в контекст (что несколько разрушает идею простых спецификаций как dto)
  • Либо сделать SpecBuilder делающий спецификацию VisibleByCurrentUser и он уже зависит от security
 demius 4 года назад

Причем и с репозиторием желательно работать по максимуму так, чтобы он использовал кеш. Например популярными считаем те, что в кеше, и если просят не больше их, то вобще не лезем в БД

 demius 4 года назад

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

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

 demius 4 года назад

У нас из коробки есть doctrine-result-cache, и когда мы просим проект по $repo->findBSuffix он может сохранить результат. Так что может и не нужны нам никакие ProjectRegistry?