Инструмент (Управление) для графического интерфейса движка правил

Question

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

Я хотел бы предоставить пользователям простой графический интерфейс, который позволил бы им взять один из «доменных» объектов нашего домена и создать правило в графическом интерфейсе, которое можно преобразовать в код XML или (в идеале) .net.

Так, например, пользователь может выбрать StaffDuty и хочет сказать: «Если сотрудник находится в группе управления, а сегодняшняя обязанность превышает 8 часов, убедитесь, что завтрашнее время подписки наступило после 08:00». Объект StaffDuty будет иметь свойства Groups, DutyTime и NextDuty, а тип NextDuty будет иметь свойство SignOn.

Я хочу иметь возможность отображать это несколько графически, когда пользователь «заполняет биты», а затем сохраняет его, чтобы мы могли затем превратить его в код (возможно, через интерпретацию xml).

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

Любые идеи приветствуются!

Answer 1

Посмотрите на разработчиков правил и выражений движка правил в Windows Workflow Foundation. Они оба предназначены для размещения вне Visual Studio. В частности, я видел пример, когда разработчику правил был передан данный тип в качестве его контекста, и он мог создавать правила и выражения на основе свойств этого типа и типов, на которые ссылаются эти свойства. Фактически можно было передать ему тип в корне графа объектов, и затем движок мог работать со свойствами всех объектов в графе.

Answer 2

Я сделал это некоторое время назад для большого правительственного механизма бизнес-правил.

Используя XML-схему для описания данных, я использовал аннотации XML-схемы для добавления во все специфические биты механизма правил, гарантируя, что схема остается действительной.

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

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

Код формы обновляет фрагмент XML, который затем переводится обратно в XML-диаграмму другим фрагментом XSLT и используется для обновления представления схемы в памяти.

После создания аннотированной XML-схемы компилятор сгенерировал две сборки .NET, одна из которых содержала кодовое представление схемы, а другая - реализацию бизнес-правил.

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

Стоимость - около 2,5 млн фунтов стерлингов, и на разработку ушло более двух лет (все дело, а не только пользовательский интерфейс). Это развитие, которым я больше всего горжусь за свои 28 лет в бизнесе!

Рад обсудить дальше, если хотите.