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

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

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

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


person emerys    schedule 27.03.2015    source источник


Ответы (1)


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

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


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

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

person Jasper van der Hoek    schedule 30.03.2015
comment
Спасибо за ответ. Я не знал, что Mendix уже использовал ehcache так, как вы описали. Я полностью согласен с тем, что я определенно не хотел бы кэшировать все или большую часть вывода Microflow. Это сделало бы приложение довольно бессмысленным. Но для некоторых микропотоков, которые не являются побочными эффектами и выполняют определенный тип деятельности, я думаю, мне может понадобиться эта возможность. - person emerys; 31.03.2015
comment
Например, если у меня есть серия микропотоков (и суб-микропотоков), которые создают объект запроса веб-службы, отправляют запрос, затем извлекают соответствующие данные из ответа веб-службы, и я знаю, что сами возвращаемые данные по своей сути кэшируется, то как лучше всего предотвратить расходование приложением ненужных ресурсов и выполнение кругового пути? Я полагаю, что просто искал способ решить эту проблему в общем, а затем применять ее всякий раз, когда она явно запрашивается. - person emerys; 31.03.2015
comment
В Mendix нет общего механизма для этого, поэтому в таком случае, когда вы можете кэшировать значения, а прирост производительности действительно важен, вам придется прибегнуть к его созданию самостоятельно. Достаточно универсальное решение может быть построено с использованием действий Java, которые могут вызывать микропотоки и сохранять возвращаемые значения в каком-то хранилище ключей/значений. Кстати, обратите внимание, что последние версии Mendix больше не используют Ehcache внутри. - person Sebastiaan van den Broek; 07.04.2015