Думаю, мне нужен простой механизм правил?[закрыто]

Question

Мне нужен совет о том, как лучше всего решить эту проблему.

Я исследовал DROOLS, Java Rule Engine и некоторые другие.Все они мощные и имеют хорошие стороны.Я не знаю, какой вариант (если таковой имеется) будет для меня лучшим выбором.

У меня есть один бизнес-объект.(упрощено для демонстрации)

Person
     firstName:String
     lastName:String
     departMent:String
     hireDate:Date

Мне нужно написать редактор в веб-приложении, который позволит строить сложные правила вокруг этих полей.Мне нужно поддерживать сложную вложенную логику И/ИЛИ.Мне просто нужны базовые операторы, и правило должно просто оценивать истину или ложь.Если правило оценивается как true или false, соответственно будет выполнено одно действие.

Например,

firstName CONTAINS "value" И (lastName EQUALS "input" OR department CONTAINS "вход")

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

Как бы вы решили эту проблему?Единственное замечание по поводу механизмов правил заключается в том, что, возможно, они слишком сложны для простой задачи?

Answer 1

Это не вопрос «да/нет», но я, вероятно, могу поделиться своим опытом и надеюсь, что это поможет. Я использовал слюни довольно успешно в нескольких проектах. Помимо некоторых случаев (у другой команды были проблемы с слюнями под тяжелой нагрузкой) слюни - довольно полезная библиотека.

Я построил приложение, которое:
1. Прочитайте ввод из источника
2. Выберите следующее действие на основе ввода из набора доступных операций

Как бы тривиально, это должно было быть очень гибким:
1. Вход был переменным набором пар именных пар, имена не предопределены.
2. Значения, наличие/отсутствие определенного имени/значений (на основе возникновения/отсутствия событий), запускают различные действия.
3. Бизнес -правила могут измениться во время работы приложения.

Может быть, есть лучшие решения, но, к лучшему или к худшему, я закончил тем, что использовал слюни. Я разработал BPEL, в котором решения принимаются компонентом слюни. Компонент слюни внутренне читает правила принятия решений из электронной таблицы Microsoft Excel. Он восстанавливает правила, если в файле есть изменение. Теперь эксперты домена меняют эту таблицу, когда это необходимо, и мы не проходим болезненные развертывания!

Если вам нужен сложный пользовательский интерфейс, Dlools Guvnor-это легко доступное веб-применение (с богатым пользовательским интерфейсом), которое поможет вашим экспертам домена/предмета построить правила и хранить их в базе данных.

Answer 2

В документации с слюнями рассказывается о том, когда использовать двигатель правил. http://downloads.jboss.com/drools/docs/5.1.1.34858.final/drools-expert/html_single/index.html#d0e181

От документов ...

Самый короткий ответ на это: «Когда нет удовлетворительного традиционного подхода к программированию для решения проблемы». Учитывая этот короткий ответ, требуется еще несколько объяснений. Причина, по которой нет «традиционного» подхода, возможно, является одной из следующих действий:

- Проблема слишком скрипает для традиционного кода.

Проблема может быть не сложной, но вы не можете увидеть не-фрагированный способ создания решения для него.

- Проблема выходит за рамки любого очевидного алгоритмического решения.

Это сложная проблема для решения, нет очевидных традиционных решений, или в основном проблема не полностью понята.

- Логика часто меняется

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

- Доменные эксперты (или бизнес-аналитики) легко доступны, но неэхнические.

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

Когда не использовать ...

Поскольку двигатели правил динамичны (динамичны в том смысле, что правила могут храниться и управляться и обновляться как данные), их часто рассматриваются как решение проблемы развертывания программного обеспечения. (Большинство ИТ -отделов, кажется, существуют с целью предотвращения развертывания программного обеспечения.) Если это причина, по которой вы хотите использовать двигатель правил, имейте в виду, что двигатели правил работают лучше всего, когда вы можете писать декларативные правила. В качестве альтернативы вы можете рассмотреть дизайн, управляемые данными (таблицы поиска) или двигатели обработки сценариев, где сценарии управляются в базе данных и могут быть обновлены на лету.

Answer 3

Я бы предложил ваш собственный анализатор. В этом контексте, почему вы не можете сериализовать объект и использовать Ajax, чтобы проверить его в заднем конце? Затем он отделяет логику проверки от пользовательского интерфейса.

Answer 4

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

Answer 5

Возможно нет.Вам нужна достойная модель домена.Не тот, где твой объекты являются просто заполнителями данных.Смогут ли ваши пользователи понять и использовать такую ​​сложную систему правил, и не предпочтут ли те, кто это делает, просто программировать на Java, где у них есть надлежащая поддержка инкапсуляции и рефакторинга?Системы правил работают только с простыми правилами в ограниченной области, где вы можете объяснить людям, не имеющим программистского образования, как их создавать.И не забывайте, что создание правил — это всего лишь программирование, поэтому вам все равно нужен контроль версий, тесты и не нужны глобальные переменные.

Answer 6

Разве Jython не был бы полезен?

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

Вы также можете поместить любые собственные объекты / переменные Java в контексте Jython, которые будут использоваться в вашем теле сценариста / функции.

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

Answer 7

Ты пытался JBEDAVE?

JBEDAVE-это основа для развития, управляемой поведением (BDD). BDD является эволюцией тестовой разработки (TDD) и дизайна, управляемого тестом, и предназначен для того, чтобы сделать эти практики более доступными и интуитивно понятны как для новичков, так и для экспертов. Он меняет словарь от основанного на тестировании на поведение и позиционирует себя как философия дизайна.