Я делаю что-то похожее на то, что вы хотите сделать.
Поскольку эти бизнес-правила очень часто устанавливаются бизнесом, я бы хотел, чтобы он внес необходимые изменения в правила через графический интерфейс.
ПРЕДУПРЕЖДЕНИЕ ПРЕДУПРЕЖДЕНИЕ ПРЕДУПРЕЖДЕНИЕ !!! Распространено заблуждение, что, пока существует графический интерфейс, непрограммисты могут его использовать. Это ... не тот вывод, к которому я пришел. Это помогает, но сложная часть программирования - это не написание кода, а поиск хороших решений нужных проблем. Я уверен, что некоторые из наиболее умных и технически подкованных деловых людей могут что-то делать с Гувнором, но не ожидайте, что это будет какая-то дорога из желтого кирпича в Страну Магического Блаженства. Вы по-прежнему должны предоставить деловым людям разумную модель данных и API, которые позволяют им делать то, что им нужно, но не позволяют им случайно сделать то, что они не хотят делать.
1. Поддерживает ли Drools упрощенный графический интерфейс для редактирования правил?
2. Drools Guvnor - это легкий графический интерфейс или есть способ отказаться от него?
Что ж, «легковесность» является предметом обсуждения, но Guvnor работает довольно хорошо и не требует больше, чем браузер, так что я думаю, что это нормально.
3. Насколько легко интегрировать приложение в Guvnor, чтобы читать правила?
Что ж, после того, как вы настроили и запустили Guvnor, настроить приложение для использования KnowledgeAgent для подключения к Guvnor и прослушивания новых обновлений правил не представляет особой сложности.
К сожалению, у Drools в целом и у Guvnor в частности есть множество причуд, которые вам, возможно, придется обойти (например, вам нужно взорвать файл Guvnor WAR и отредактировать файлы в WEB-INF / beans.xml, чтобы настроить не- конфигурация по умолчанию ...). Но как только вы это исправите, я думаю, что это работает очень хорошо.
Что касается документации, Javadocs может быть немного скудным, но на веб-сайте есть довольно хороший материал, в том числе несколько книг.
В общем, Drools и Guvnor - мощные инструменты, но заставить их работать нетривиально. Если вам действительно нужно то, что они предлагают, они того стоят, но, возможно, стоит подумать, хватит ли более простого скриптового решения.
Теперь, если вам действительно нужны Drools, вот мой главный совет - держите отдельные модели данных для своей базы данных и правил. Это означает, что нужно написать много скучного кода преобразования, но оно того стоит.
Приложение, над которым я работаю, использует JPA для работы с базами данных, и было бы не очень приятно использовать эту модель данных в наших правилах. Некоторые причины:
То, что подходит вашему уровню данных, не обязательно соответствует Drools, и наоборот.
У нас есть древовидная структура, которая в JPA, естественно, является @OneToMany отношением к дочерним элементам в списке в родительском узле. Работа со списками в Drools была довольно болезненной, поэтому мы свели ее к структуре, в которую вставляем один ParentNode объект и несколько ChildNode объектов, с которыми было намного проще работать.
Проведите рефакторинг.
Модель данных правила также должна находиться внутри Guvnor - а это означает, что вы можете нарушить все правила, если переименуете класс сущности или что-то в этом роде. Отдельная модель данных для правил означает, что вы можете без проблем провести рефакторинг базы данных.
Покажите им то, что им нужно увидеть.
Базы данных могут становиться довольно сложными, но правила обычно не заботятся о многих из этих сложностей. Предоставление этих сложностей людям, редактирующим правила, может вызвать излишнюю путаницу. Например, мы обнаружили, что для наших сценариев нет абсолютно никакой необходимости подвергать авторов правил отношениям «многие ко многим» (которые оказались очень сложными для обработки в Drools) - поэтому вместо этого мы делаем их похожими на отношения «один ко многим». , и все становится более естественным.
Защита.
Мы разработали большинство наших правил для работы как этот псевдокод:
rule "Say hello to user"
when
user : User
then
insert(new ShowMessageCommand("Hello " + user.getName() + "!"))
end
... и поэтому для каждого пакета правил четко определено, какие ответные команды вы можете вставлять и что они делают. После запуска правил в нашем приложении мы выбираем объекты, вставленные в сеанс с помощью правил, и действуем в соответствии с ними (шаблон посетителя оказался очень полезным для избежания длинных _6 _ / _ 7 _ / _ 8_ цепочек).
Я очень рад, что мы сделали это таким образом, вместо того, чтобы позволить разработчикам правил делать то, что они думают, что они хотят делать с нашими объектами JPA.
В любом случае, надеюсь, это поможет.
person
gustafc
schedule
28.06.2012
