Комментарии 9
Не подкажете, у какой фин. организации вы на аутсорсе? Чтобы знать, чьими услугами не пользоваться :)
А если серьёзно, лично я являюсь ярым противником запуска произвольного юзерского кода у себя на сервере. При таких простых правилах вряд ли можно получить доступ к переменным окружения. Но я полагаю, что у вас есть поддержка мат.операций и пользователь может создать правило, к примеру, с факториалом от 100? И тогда как минимум улетит ваш облачный бюджет.
Здравствуйте, таких праивл нет, правила создаются исключительно по схеме данных(это, кстати, указано в статье), произвольного запуска кода тоже нет. Мат операций произвольных тоже нет, собственно они не нужны. Валидация происходит по аттрибутам на модели, так что если даже мы введем мат операции, то только те, которые мы сами заапрувим, об этом тоже указано в статье.
Облачный бюджет чувствует себя прекрасно, спасибо.
Эмм, ну может я недостаточно внимательно читал, но из этого абзаца я понял, что я могу себе настроить произвольные нотификации.
К примеру: пользователь следит за движением цен на алюминий и хочет получить уведомление, как только цена превысит какое-то определённое значение. С помощью функции нашего приложения он может создать правило, которое проинформирует его о нужном событии в момент наступления.
А как мне обойтись без мат. операций, если я хочу, к примеру, получить уведомление, если цена на алюминий выросла на 5%? Нужно иметь же возможность записать что-то вроде newPrice > oldPrice * 1.05, разве нет?
Нет, это совершенно не обязательно, для этого можно использовать поля в модели, к примеру если вы хотите поддержку каких-то сложных вычислений будет практичнее, как вы и сказали, расчитывать все самим, а пользователям давать уже упрощенный интерфейс для доступа к таким данным.
В том примере который вы описываете решение следующее - мы просто имеем поле в модели, которое уже содержит нужные данные, а именно дельту в процентах, ну или дельту в еденицах измерения самого инструмента. Поэтому мы просто вводим это поле в нашу модель и используем его.
По поводу подхода и решения, в статье никто не претендует на святой грааль и на единственно правильный способ, я лишь описал практический опыт и его примеение. Он может вам не подходить от слова совсем и это абсолютно нормально.
Пользовательские и произвольные - понятия разные ;)
Однажды у нас был косяк, когда нужно было сгенерировать preview для документа, который создал пользователь (читай хавать произвольные данные). Для этого мы использовали Headless chrome, я обмазал все try/catch и retry policy, но всё равно прилетел документ, где пользователь нафигачил огромных картинок и в итоге браузер завис в отдельном процессе без возможности его как либо убить, кушая 100% CPU на AppService Plan'е.
Еще раз, пользователь может что-то сделать в нашем приложении только используя конкретную схему данных. Он не сможет прислать чего-то что мы, в нашей схеме данных, не разрешаем.
У вас произвольные данные, у нас наши собственные, расширяем их мы сами, у пользователя нет прямого влияния на них. При чем в глубине еще есть валидация по метаданным.
Это очень-очень похоже на систему компоновки данных в 1С. Надо будет воспользоваться этим, когда буду создавать что-то похожее
Компилятор бизнес-правил на основе деревьев выражений