Каковы плюсы и минусы использования механизмов правил Java JESS и Слюни? Есть ли другие игроки?
Я понимаю, что Drools — это Open Source, а JESS — нет, но как они соотносятся в других областях, таких как простота использования, производительность, уровень интеграции с вашим кодом?
Каковы плюсы и минусы использования движков правил Java JESS и Drools?
Используйте обработчик правил, если вам нужно отделить бизнес-правила от логики приложения. В статье Нужен ли вашему проекту механизм правил есть хороший пример:
Например, типичная система витрины может включать код для расчета скидки:
if (product.quantity > 100 && product.quantity < 500) { product.discount = 2; } else if (product.quantity >= 500 && product.quantity < 2000) { product.discount = 5; } else if (product.quantity >= 2000) { product.discount = 10; }Механизм правил заменяет приведенное выше кодом, который выглядит следующим образом:
ruleEngine.applyRules(product);
Вам решать, хорошо ли передавать консоль администратора правил в руки нетехнических людей :)
Дополнительные сведения см. в разделе Должен ли я использовать механизм правил?, Зачем использовать механизм правил?, Некоторые рекомендации по принятию решения об использовании механизма правил и на Google.
Есть ли другие игроки?
Другие игроки включают JRules, Corticon (JRules — самый известный IMO, что не означает лучший).
как они соотносятся в других областях, таких как простота использования, производительность, уровень интеграции с вашим кодом?
Точно сказать не могу, у меня только небольшой (положительный) опыт работы с Drools. Но вы получите отзывы из таких сообщений в блогах, как JBoss Drools. vs ILog JRules — анекдотическая история (обязательно прочитайте) или Работа с Drools с точки зрения JRules. Я уверен, что вы можете найти больше из них в Google (но я бы попробовал Drools).
Сейчас мы оцениваем правила для использования с нашим сервером приложений. Мы столкнулись с OpenRules, который легко интегрируется с Java и, как показало наше тестирование, достаточно быстро . Основное преимущество OpenRules перед другими заключается в том, как правила изменяются и обрабатываются. Все это происходит в таблицах Excel, что является самым простым способом для непрограммистов. Все причастные, даже не технические люди, все прекрасно поняли :-)
У нас также есть интегрированные drools, но правила намного сложнее понять, поскольку это более программный подход. Поэтому мы, скорее всего, будем придерживаться OpenRules.
У нас был похожий вопрос, мы наконец-то взяли Drools, нужно использовать drools, если у вас есть следующие:
Дополнительные сведения см. по следующему URL.
Просто добавим, что многие люди ищут что-то более похожее на управление выполнением определенных условий для включения или отключения определенных функций в приложении.
Я устал от повторной реализации одного и того же шаблона снова и снова, где бы я ни был, поэтому я решил создать для него проект OSS под названием Roolie http://sourceforge.net/projects/roolie/
Я только что сделал его maven, и, поскольку с 2010 года, когда он был выпущен, не было сообщений об ошибках, я обновил его до версии 1.0 без каких-либо изменений, кроме тех, которые необходимы для его размещения в Maven Central (что я в процессе). ).
По сути, JSR-94 является излишним для большинства вещей, и существует огромная кривая обучения и накладные расходы, связанные с текущими предложениями. Это нормально, если ты этого хочешь. Но если вы просто хотите связать простые правила, написанные на Java, вместе с XML для поддержки ваших тестов состояния, Roolie — очень быстрый способ сделать это. Никаких зависимостей и кривой обучения.
Когда нам понадобился движок правил, мы решили создать свой собственный, потому что доступные были слишком сложны для наших простых задач. Если вы хотя бы отдаленно разбираетесь в выражениях, которые могут вводить пользователи, это не очень сложно сделать. В нашем случае большая часть спецификации обрабатывается XSD, и только несколько полей анализируются дальше.
