Если уже идти во все тяжкие оптимизации, то зачем вообще держать множества для страниц?
Можно обойтись простым <userId>: <string>. При этом не пустое значение будет означать, что у пользователем посещена только эта страница. А пустое значение - признак посещения более одной страницы. Т.е.
Первый день:
Если пользователя (ключа) нет в коллекции, то добавить туда вместе со значением страницы
Если пользователь есть, и значение страницы пустое, то пропустить.
Если пользователь есть, и значение страницы не совпадает с текущим, то заменить его на пустоту.
Второй день:
Если пользователь есть, и у него либо пустая строка (признак), либо строка не совпадает - то это лояльный пользователь.
Спасибо, попробую! Вообще, я больше хотел популяризовать ValueResolver, в котором можно самостоятельно вклинится в алгоритм переливания запроса в дто. Если Mapping Request Data обладает такой же гибкостью, то супер!
- Здравствуйте, желаете поговорить об апиплатформ? У нас контроллеры светятся от счастья, но на алтарь пойдут ваши модели, мы нашинкуем их дополнительными атрибутами, эти атрибуты с помощью других атрибутов перемешаем по группам (поверьте, это так удобно!), подсадим на круд-иглу, и политику доступов тоже заберем себе. Интересует? - Спасибо, но мне бы просто генератор апи интерфейса (которым даже пользоваться будут в основном для экспорта в постмен/инсомнию).
Но теперь на их главной странице красуется ApiResource, без каких-либо обязательств. И я в растерянности) Возможно сам себе навертел это все на мозги.
Не уверен, что понял вопрос. Поэтому если отвечу не то, не обессудь)
Контроллер с его сигнатурой входа/выхода - это и есть интерфейс (контракт). А его реализация - сервис, где можно задействовать вот это вот всё. Так что здесь отображение кода не мешает ООП, а лишь гарантирует достоверность спецификации (хоть и делает ее более куцей). За кадром остались тесты, которые будут следить, чтобы контракт конкретной версии апи не поменялся. Но если документация использует не код, а дополнительные нотации - то тесты ее не защитят.
Большое спасибо! Наши фронты тоже поддержали эту мысль, что "сила в правде", и работать с актуальным апи без купюр лучше, чем с намарафеченной хнёй. Кажется, искусственное описание вместо отображения реальности - поворот не туда.
Если уже идти во все тяжкие оптимизации, то зачем вообще держать множества для страниц?
Можно обойтись простым <userId>: <string>. При этом не пустое значение будет означать, что у пользователем посещена только эта страница. А пустое значение - признак посещения более одной страницы. Т.е.
Первый день:
Если пользователя (ключа) нет в коллекции, то добавить туда вместе со значением страницы
Если пользователь есть, и значение страницы пустое, то пропустить.
Если пользователь есть, и значение страницы не совпадает с текущим, то заменить его на пустоту.
Второй день:
Если пользователь есть, и у него либо пустая строка (признак), либо строка не совпадает - то это лояльный пользователь.
Спасибо, попробую! Вообще, я больше хотел популяризовать ValueResolver, в котором можно самостоятельно вклинится в алгоритм переливания запроса в дто. Если Mapping Request Data обладает такой же гибкостью, то супер!
Мое знакомство с этой штукой было примерно таким:
Но теперь на их главной странице красуется ApiResource, без каких-либо обязательств. И я в растерянности) Возможно сам себе навертел это все на мозги.
Не уверен, что понял вопрос. Поэтому если отвечу не то, не обессудь)
Контроллер с его сигнатурой входа/выхода - это и есть интерфейс (контракт). А его реализация - сервис, где можно задействовать вот это вот всё. Так что здесь отображение кода не мешает ООП, а лишь гарантирует достоверность спецификации (хоть и делает ее более куцей). За кадром остались тесты, которые будут следить, чтобы контракт конкретной версии апи не поменялся. Но если документация использует не код, а дополнительные нотации - то тесты ее не защитят.
Большое спасибо! Наши фронты тоже поддержали эту мысль, что "сила в правде", и работать с актуальным апи без купюр лучше, чем с намарафеченной хнёй. Кажется, искусственное описание вместо отображения реальности - поворот не туда.