Правила, управляемые данными Двигатель - Drools

Ответ 1

Вы попросили меня ответить на ваш вопрос, учитывая мой ответ на Бизнес-правила, управляемые данными. Мой ответ на этот вопрос заключался в том, что SQL - это плохое решение для выполнения бизнес-правил, хранящихся в базе данных. Человек, который задал этот вопрос, хотел генерировать выражения SQL из своих хранимых бизнес-правил, и я предостерег от этого, потому что это приведет к проблемам безопасности, тестируемости, производительности и обслуживания.

Я не использовал Drools, но из документации я собираюсь включить в него Guvnor, менеджер бизнес-правил, который поддерживает использование RDBMS в качестве репозитория для пользовательских правил.

[Drools] Guvnor использует стандарт JCR для хранения таких активов, как правила. По умолчанию используется Apache Jackrabbit, http://jackrabbit.apache.org. Это включает в себя механизм/базу хранения ящиков, который вы можете использовать как есть, или настроить, если необходимо, использовать существующую СУБД. (http://docs.jboss.org/drools/release/5.2.0.Final/drools-guvnor-docs/html/chap-database_configuration.html)

Apache Jackrabbit не является РСУБД, это "хранилище контента - это хранилище иерархического контента с поддержкой структурированного и неструктурированного контента, полнотекстового поиска, управления версиями, транзакций, наблюдения и т.д.". Это похоже на более подходящий репозиторий для Drools.

Но Drools не говорит, что пытается использовать SQL для выполнения этих бизнес-правил. Для этого есть отдельный компонент Drools Expert (Rules Engine).

Drools Expert - это декларативная, основанная на правилах, среда кодирования. Это позволяет сосредоточиться на том, "что вы хотите делать", а не "как это сделать". (http://www.jboss.org/drools/drools-expert.html)

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

Итак, я бы предложил, если вы используете Drools, не стесняйтесь использовать СУБД как репозиторий, поскольку они документируют (используйте их JCR-совместимую реализацию репозитория контента, не пытайтесь создавать свои собственные). Затем используйте их Drools Expert как специализированный язык, предназначенный для выполнения правил.

Ответ 2

• Нет значимого интерфейса, который я могу предложить конечным пользователям для изменения правил.

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

• Пользовательский интерфейс Guvnor или любой редактор для изменения drl файлов просто неприемлем с точки зрения конечного пользователя

Как уже упоминалось, Guvnor поддерживает таблицы решений. Если вам не нравится макет веб-приложения Guvnor, вы можете просто встраивать редакторов Guvnor в свое собственное веб-приложение.

• Большинство этих правил будут работать на часто огромных данных, доступных в db

Размер вашей базы данных не имеет отношения к использованию Guvnor. Guvnor предназначен для редактирования правил, а не для оценки времени исполнения. Drools Expert - это механизм правил выполнения. Это быстро. Он может обрабатывать очень большие объемы данных и очень большие объемы правил. Все, что вам нужно сделать, это написать запросы к базе данных, чтобы получить соответствующие куски этих данных в движке правил во время выполнения. Вам нужно это сделать, независимо от того, что вы пытаетесь реализовать.

На стороне примечания, если то, что вы действительно знаете, является объяснением того, когда механизмы правил являются хорошими (и плохими) решениями проблемы, тогда я бы рекомендовал прочитать Зачем использовать раздел "Механизм правил" в руководстве Drools Expert.

Ответ 3

Как правило, я обнаружил, что легче работать на более абстрактном уровне, таком как модель домена, и иметь какое-то программное преобразование от правил к правилам Drools, а не напрямую обращаться к правилам Drools. Таким образом, вы можете сохранить свою модель домена, как вам нравится, и вы можете создавать пользовательские интерфейсы вокруг нее и т.д. И все еще иметь возможность генерировать правила Drools по требованию. Тогда вызов с этим - это создание программной трансформации из вашей модели в правила Drools, но здесь помогут инструменты шаблонов. Я использовал Groovy templating для этого, и он работал хорошо.