Плюсы и минусы механизмов правил Java

Каковы плюсы и минусы для использования механизмов правил Java JESS и Drools? Есть ли другие игроки?

Я понимаю, что Drools - это Open Source, а JESS - нет, но как они сравниваются в других областях, таких как простота использования, производительность, уровень интеграции с вашим кодом?

Ответ 1

Каковы плюсы и минусы для использования механизмов правил 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 - самая известная ИМО, что не значит лучшее).

как они сравниваются в других областях, таких как простота использования, производительность, уровень интеграции с вашим кодом?

Не могу точно сказать, у меня есть только небольшой (положительный) опыт с Drools. Но вы получите некоторую обратную связь из сообщений блога, таких как JBoss Drools против ILog JRules - анекдотическая история (обязательно прочитайте) или Работа с Drools с точки зрения JRules. Я уверен, что вы можете найти их больше в Google (но я бы попросил Drools попробовать).

Ответ 2

Теперь мы оцениваем правила для использования с нашим сервером приложений. Мы встретили OpenRules, который легко интегрировать с Java и, насколько показывает наше тестирование, достаточно быстро. Основным преимуществом OpenRules выше oters является то, как правила изменяются и обрабатываются. Все это происходит в таблицах Excel, что является самым простым способом для не-программистов. Все вовлеченные, даже нетехнические люди, все прекрасно понимали: -)

У нас также есть слюни, но правила намного сложнее понять, поскольку это более программный подход. Вот почему мы - скорее всего - будем придерживаться OpenRules.

Ответ 3

У нас был с нами подобный вопрос, мы, наконец, подняли Drools, нужно использовать слюни, если у вас есть следующее:

  • Бизнес-логика, которая, по вашему мнению, захламлена множеством ситуаций if из-за множества сценариев.
  • У вас будет растущий спрос на увеличение сложности
  • Изменения бизнес-логики будут частыми (1-2 раза в год также будут частыми)
  • На вашем сервере достаточно памяти, так как это голодный инструмент, обеспечивающий производительность по стоимости памяти

Подробнее см. URL

Ответ 4

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

Я устал повторять одну и ту же модель снова и снова, куда бы я ни пошел, поэтому решил сделать для нее проект OSS под названием Roolie http://sourceforge.net/projects/roolie/

Я просто отключил его, и поскольку с 2010 года, когда он был выпущен, ошибок не было, я обновил его до версии 1.0 без каких-либо изменений, кроме тех, которые требуются для его размещения в Maven Central (который я нахожу в процесс выполнения).

В принципе, JSR-94 является чрезмерным для большинства вещей, и есть огромная кривая обучения и накладные расходы, которые идут вместе с текущими предложениями. Это прекрасно, если вы этого хотите. Но если вы просто хотите связать простые правила, написанные на Java вместе с XML, чтобы поддерживать свои государственные тесты, Roolie - это очень быстрый способ сделать это. Никаких зависимостей и кривой обучения.

Ответ 5

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