2016-11-03 5 views
0

Я начинаю проект, где у нас много бизнес-правил. Я настоятельно рассматриваю использование механизма правил JBoss, Drools.Drools on Spark with Scala

В моем проекте используется Scala и используется двигатель Spark. Мне интересно, есть ли у кого-нибудь опыт или советы, используя Drools с Spark/Scala.

Если вы посмотрели на Дролса и решили против него, я тоже хотел бы это знать.

Я прочитал несколько блогов о том, как люди объединяют Drools с Spark или Drools с Scala, но я не нашел хороших примеров, объясняющих Drools на Spark с Scala. Я видел это со смесью Scala и Java, но никогда не чистая Scala. Я не уверен, что это возможно.

Update: Очищающий Вопрос

  1. Вы рекомендовали бы Drools?
  2. Как насчет Spark/Scala?
+0

Что вы хотите сказать? – eliasah

+0

Привет, наконец, что вы решили? С слюнами или с слюнами? –

+0

Я приземлился, идя с Дрослом. До сих пор он хорошо работал. Самая сложная часть заключается в том, как правила создаются. У меня есть тысячи правил, которые затрудняют поддержку в файлах DRL и таблицах решений. Инструмент для слюнки также не идеален для моей ситуации. Я приступлю разработку собственного инструмента создания. – terminatur

ответ

2

Если вы смотрели в Drools и решил против этого, я хотел бы знать, что тоже.

Я бы не советовал это. Мы вынуждены использовать Drools в одном из наших компонентов и все разработчик в команде найти это решение полных минусов:

  1. Java 8 поддержки: Scala двигается к Java 8 (см this и this относительно выполнения). Drools начал поддерживать java 8 только через 2 года после его выпуска.
  2. IDE-поддержка: только затмение. Мы не смогли это сделать в Идея Intellij.
  3. Общее назначение: мы придумали идею, что бы вы ни делали пишите, используя двигатель drools rules, можно легко написать в java/scala . Вы могли бы сказать, что бизнес-логика может стать слишком технической? Возможно, вам не нужно было изучать какой-то язык сценариев для создания бизнес-правил.
+0

Номер 3 очень спорный. После того, как вы попытаетесь выйти за рамки примеров «сыра» в руководстве Drools, вы обнаружите, что решение многих проблем совпадения, в общем, легче сделать с помощью механизма, основанного на правилах. Вложенные петли глубиной три или более с возможной сложной логикой на каждом уровне для фильтрации желаемых компонентов * могут * быть записаны, но, как правило, оказываются кошмаром для обслуживания. - Обратите внимание, что существуют системы принятия решений с меньшими накладными расходами, чем Drools, но это не означает, что ваш № 3 является универсальной истиной. – laune

+0

1. Не могли бы вы подробнее рассказать о том, что вы имеете в виду для Java 8? 2. Я бы использовал рабочее место KIE. Вы использовали это? – terminatur

0

1) Да, я бы рекомендовал Drools. У меня нет опыта работы с другими механизмами правил, но проекты, которые я разработал с помощью Drools, отлично работали до сих пор. По правде говоря, я использовал только базовые функции Drools (никогда не использовал ясность явно, Agendas и т. Д.). Однако функциональность, которую я использовал, полностью меняла мои требования.

2) Я использовал Drools как с Java 7, так и с Scala 2.11. Я не нашел ничего конкретного, что мог сделать с Java, но не в Scala. Мой последний проект использует Apache Spark с Scala и Drools, и все прекрасно сочетается.

Если вы собираетесь использовать Scala, то ваши факты (объекты, которые моделируют ваш домен, aka «bean»), должны иметь модификаторы общего доступа в val или var, к которым вы собираетесь получить доступ в рамках правил. Если вам нужны статические методы или атрибуты, используйте объекты и импортируйте их в файл правила.

Надеюсь, что это поможет