Инструмент (управление) для GUI правила управления

Question

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

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

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

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

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

Любые идеи оценены!

Answer 1

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

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

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

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

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

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

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

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

С удовольствием обсудим, если вы хотите.

Answer 2

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