DSL: из правил DSL в выражения C # - PullRequest
Новая
       19

DSL: из правил DSL в выражения C #

1 голос
/ 03 июня 2009

вопрос может быть сложным, позвольте мне расширить его:

  • существует ли дизайнер (заглушка / фреймворк / мета-дизайнер) для создания правил на основе И / ИЛИ на основе общих свойств bool объекта .NET? Сохраняется как любой выход DSL / Boo / ....
  • возможно ли скомпилировать вывод DSL в выражения C # ?

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

Если мы можем предоставить простой конструктор пользователям и получить выходные данные, то после преобразования / компиляции его в код C # / IL у нас будет цикл запроса на быстрое изменение.

Я знаю, что наша проблема специфична, но любые "кирпичи в стене" приветствуются!

Пример : * * тысяча двадцать-один

Класс C #, предмет: 

public class TestA
{
     public bool B {...}
     public bool C {...}
}

В конструкторе мы должны иметь возможность создать

  • любой тип графических дизайнеров (т. Е. Выпадающий список для выбора общедоступных свойств)

Вывод в DSL: 

If TestA.B AND TestA.C Then Return True;

Вывод в C #: 

if (testA.B && testA.C) { return true; }

Обновление № 1

Я был бы рад языку DSL, который поддерживает использование классов .NET со статической типизацией. Я имею в виду, что если пользователь может проверить код ( "Вывод в DSL" в примере), нам не нужен дизайнер.

Обновление № 2

Исходя из подсказки, я смотрел с деревьями выражений. Через несколько дней я столкнулся с DLinq - я никогда не был большим поклонником DLinq, но в этом случае очень хорошо подходит для проблемной области.

  • Легко анализировать (A> 2 И B <4) ИЛИ C = 5 </em> в деревья выражений
  • Легко создавать подобные выражения
  • Очень легко сериализовать / десериализовать
  • Графический интерфейс, основанный на FlowLayoutPanel, прекрасно работает как «построитель выражений»

Ответы [ 2 ]

5 голосов
/ 04 июня 2009

Вы можете создать что-то подобное себе.

Вы можете получить список всех открытых свойств для класса с помощью Type.GetMembers ()

Однако вместо генерации кода на C # я бы использовал деревья выражений.

Таким образом, вам не нужно привлекать компилятор C #, когда пользователи меняют правила. Вместо этого вы можете сохранить правила в базе данных, загрузить их во время выполнения, а затем использовать метод Expression.Compile () для создания делегата, который вы можете вызывать для запуска кода.

Обновление:

В комментариях кто-то спросил: «В чем разница между Expression Tress и языками, специфичными для домена?»

Вот ответ:

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

Выражения tress - это просто API для представления выражений C #, которые удобно динамически преобразовывать в делегат во время выполнения.

DSL, или предметно-ориентированный язык, - это язык программирования, предназначенный для решения узкого класса проблем.

Это, по сути, совершенно разные вещи.

Вы можете использовать деревья выражений как часть реализации DSL, если хотите. Линк использует их для этой цели.

В вашем случае, однако, вам не нужен DSL. Вам нужен пользовательский интерфейс, который генерирует правила (аналогично тому, как работает outlook), а затем способ их выполнения.

Создание пользовательского интерфейса - это просто нормальная разработка пользовательского интерфейса.

Деревья выражений - это то, что вы можете использовать для реализации правил.

0 голосов
/ 12 июля 2009

Это малоизвестный факт, что конструктор для Windows Workflow Foundation и, в частности, его Engine Rules можно размещать в приложении Windows Forms, отдельном от Visual Studio. Правила, созданные таким образом, могут также оцениваться независимо от фактического рабочего процесса.

См. Руководство по сценариям WF: повторный хостинг дизайнера рабочих процессов и Учебное пособие: хостинг дизайнера WF .

...