Слюни - делать сложные вещи внутри условия или следствия правила

Question

В моей компании мы планируем использовать Drools BRE для нескольких проектов. Сейчас мы пытаемся определить некоторые лучшие практики.

Мой вопрос заключается в том, что следует и чего не следует делать в условии / следствии правила. Учитывая, что мы можем писать Java напрямую или вызывать методы (например, из глобального объекта в рабочей памяти).

Пример. Для данного правила, которое оценивает универсальный объект (например, Person), свойство имеет значение true. Теперь эта конкретная собственность может быть определена только для этого Объекта, идущего в базу данных и извлекающего эту информацию. Таким образом, у нас есть два способа реализации этого:

Альтернатива A:

• Перейти в базу данных и получить свойство объекта (true / false, код)
• Вставить объект в рабочую память
• Оценить правило

Альтернатива B:

• Вставьте глобальный объект, у которого есть метод, который подключается к базе данных, и проверьте свойство для данного объекта.
• Вставить объект для оценки в рабочей памяти
• В правиле вызвать глобальный объект и выполнить доступ к базе данных

Что из этого считается лучше? Мне действительно нравится A, но иногда B более прост, однако, что произойдет, если возникнет что-то вроде исключения из базы данных?

Я видел альтернативу B, реализованную в книге Drools 5.0 от Packt Publishing, однако они издеваются и не говорят о реальных последствиях обращения к базе данных.

Спасибо,

Answer 1

Одна из особенностей правил заключается в том, что они могут выполняться много, много раз.Особенно, если вы делаете ошибку с условиями вашего правила.Это, очевидно, влияет на производительность.

Я склонен затем предпочесть вариант А, подготовить ваши факты снаружи и вставить их в рабочую память для оценки.

Конечно, есть также возможность разделения правил на загрузку данныхправила, а затем оценка бизнес-правил (например, с использованием потока правил).

Это даст вам декларативный контроль над заполнением ваших данных вне кода.

Answer 2

У меня также есть необходимость извлекать внешние данные из другой системы (база данных, сервисные вызовы и т. Д.), Поэтому я немного с этим справился.Лично я бы принял это решение, основываясь на том, будете ли вы знать, какие факты вам понадобятся заранее.Если это так, то непременно совершайте звонки на Java.Это позволит вам лучше обрабатывать ошибки.И если неспособность извлечь определенные данные означает, что запуск механизма правил запрещен, вы избежите работы по созданию сеанса, вставке фактов, настройке глобальных переменных и так далее.Нет смысла запускать его, если вы просто собираетесь остановить ().

Но, конечно, бывают и случаи, когда невозможность получить данные не должна помешать вам работать.В некоторых из этих случаев Альтернатива А и В будут работать одинаково хорошо.Но предположим, что необходимость определенных данных зависит от других вещей.Например, я работаю над приложением, которое оценивает, что по сути являются большими логическими деревьями, а листья оцениваются с использованием данных из вызовов служб.Если два листа были AND и вместе, так что оба должны были быть истинными, чтобы их ветвь была истинной, как только один из них оценивается как ложный, эта ветвь становится ложной, и мне больше не нужно оценивать другой лист.Это означает, что было бы бесполезно предварительно загружать данные, которые мне понадобились бы для их оценки.Получение данных «по требованию» является одной из причин того, что механизмы правил, такие как Jess, также поддерживают обратное сцепление в дополнение к прямому сцеплению по умолчанию.

До тех пор, пока обратное сцепление не будет завершено вСлюни, альтернатива, которую я видел, предлагает использовать ключевое слово "from" .Мне повезло с этим, но есть две вещи, на которые следует обратить внимание:

1. Drools неоднократно запрашивает оператор "from" во время работы механизма правил.Я использую кеширование в своем слое обслуживания, так что это так же вредно, как поиск в HashMap, но если вы не кешируете, вы рискуете неосознанно совершать десятки, сотни или тысячи вызовов сервисов.
2. Если выне найти данные, которые вы ожидали, нет места для обработки ошибок.Это то, на что намекал Стивен Ирод.Механизм правил продолжит работу и продолжит оценивать выражение, которое вы ему дали.В ситуациях, когда мне нужно было выполнить какое-то действие, например, вызвать halt (), я вместо этого сделал сервисный вызов в соответствии с правилом.

Надеюсь, это поможет.Дайте мне знать, если есть что-то, что я могу уточнить или расширить.