Кэширование и АОП в Мендиксе: существует ли унифицированный или стандартизованный подход для кеширования на стороне сервера в приложении Mendix?

Question

Использование Mendix Business Modeler для создания веб-приложений принципиально отличается от разработки веб-приложений с использованием таких технологий, как Java/Spring/JSF. Но я попытаюсь сравнить эти два вопроса для этого вопроса:

В приложении Java/Spring я могу интегрировать свое приложение с сторонним продуктом Ehcache для кэширования данных на уровне метода. Например, я могу настроить ehcache для хранения возвращаемого значения для данного метода (с определенным временем жизни). Всякий раз, когда вызывается этот метод, ecache автоматически проверяет, был ли метод ранее вызван с теми же параметрами, и если в кеше хранится возвращаемое значение. Если это так, метод никогда не выполняется, и вместо этого возвращается возвращаемое значение кэшированного метода.

Я хотел бы иметь те же возможности в Mendix, но в этом случае я бы стал кешировать значения возврата Microflow. Кроме того, я не хочу, чтобы меня заставили добавлять действия по всему месту, явно указывая Microflow на проверку кеша. Я хотел бы зарегистрировать мой Microflows для кеширования в одном централизованном месте или просто отметить каждый Microflow для кэширования. Другими словами, этот вопрос в равной степени связан с концепцией аспектно-ориентированного программирования (AOP) в Mendix как о кешировании: есть ли способ получить крючки в вызове Microflow, чтобы я мог применять операции до и после выполнения? По моему мнению, те же причины, по которым АОП имеет место в Java, существуют в Mendix.

Answer 1

При работе с приложением Mendix он пытается сделать как можно больше для вас, в этом случае это означает, что платформа уже имеет кеш объекта, чтобы сохранить все объекты, которые нуждаются в кешировании. Внутренне платформа Mendix использует Ehcache для этого.

Однако на этот кеш невозможно влиять, как это обычно бывает в Java/Spring. Это связано со всеми функциональными возможностями платформы Mendix, которая уже пытается максимально эффективно кэшировать все объекты.
Каждый объект, который вы создаете, всегда добавляется в кеш. При работе с этим объектом он остается в кеше до тех пор, пока платформа не обнаружит, что конкретный объект больше не может быть доступен ни через интерфейс пользователя, ни через микропоток. Доступны также вызовы API, которые инструктируют платформу сохранять объект в кеше независимо от его использования. Но это не дает вам гибкости, как вы просили.

Но, в частности, на ваш вопрос, мой первоначальный ответ был бы следующим: почему вы хотите кэшировать выход микропотока?
Объекты уже кэшируются в памяти, и клиент браузера только обновляет кеш при указании. Любые объекты, которые вы используете, будут кэшироваться. Также, глядя на большинство микропотоков, которые мы используем, я не думаю, что, скорее всего, я захочу кэшировать вывод вместо повторного запуска микропотоков. Из-за конструкции большинства микропотоков я думаю, что большинство микропотоков могут возвращать несколько разные результаты каждый раз, когда вы его выполняете.

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