Какую технологию использовать в создании DSL для механизма правил?

Другой возможно интересная альтернатива должен использовать цитаты F#.

Цитаты позволяют Вам рассматривать часть программы как данные, таким образом, можно получить AST, проанализировать его и перевести его на другой язык или выполнить его некоторым нестандартным способом. Вместе с гибкостью F# необходимо смочь выразить много вещей, таким образом, необходимо было бы разработать внутреннюю библиотеку F# DSL/combinator для описания правил и переводчика/интерпретатора для цитат F# для выполнения их.

Не уверенный, как бизнес-правило могло бы быть похожим, но Вы могли записать что-то вроде этого:

let rule = <@
  if (exists customer having validEmail) then success
  else require whatever 
@>

Я записал введение в эту тему на моем блоге. Unfortunatelly, были некоторые большие изменения в F# CTP, и я еще не обновил исходный код, но он должен дать Вам хорошую идею того, что является возможностями и ограничениями этого подхода.

• Образцы цитат F# на CodePlex - TomasP.Net

Хорошим примером DSL является платформа поблочного тестирования F#:

• Объявление о FsTest - тестирование DSL для F# - Matthew Podwysocki

[РЕДАКТИРОВАНИЕ] Просто для уточнения, почему я думаю, что это может быть хорошим подходом:

• Если Вы будете использовать Visual Studio для редактирования DSLs (и можно использовать версию Shell с F#, установленным бесплатно), то Вы получите очень хороший опыт редактирования бесплатно. Не только подсветка синтаксиса, но также и IntelliSense это предложит возможные конструкции и также фоновую проверку типа, которая служит средством проверки 'грамматики' для Вашего DSL.
• По сравнению с другими подходами этот - возможно, один из самых легких для реализации.
• Единственное ограничение - то, что Вы ограничены синтаксисом F#. Однако разработка Вашего собственного языка является действительно трудной, таким образом, это не может быть этим плохо вообще. Особенно учитывая гибкость F#.

[/РЕДАКТИРОВАНИЕ]

Надеюсь, это поможет!

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

Вы очень более обеспечены с текстовым языком для описания бизнес-правил.

Для получения феночерного пользовательского опыта для редактирования кода, Вам нужно:

1. Синтаксический анализатор с хорошим восстановлением после ошибки
2. Способность сделать возрастающую перекомпиляцию

Хорошее восстановление после ошибки позволяет Вам эффективно определять намерение программиста от синтетически неполных конструкций. Это крайне важно для реализации intellisence.

Способность сделать возрастающую перекомпиляцию дает Вам способность сделать efficent фоновую компиляцию в ответ на пользовательские редактирования.

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

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

Реализация efficent перекомпиляция требует, чтобы Вы смогли: 1) Надлежащего разрушения семантического анализа в фазы (для чего-то как C# это было бы: сначала создайте пространство имен и символы текста, затем разрешите операторы использования, затем разрешите базовые классы, и т.д.). 2) Способности создать осведомленный о фазе граф зависимостей 3) Алгоритмы для обработки графа зависимостей и лишения законной силы частей его в ответ на пользовательские редактирования

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

Так, я запустил бы с синтаксического анализатора и затем создал бы intellisence сверху его.

Если можно избежать интеграции VS, я был бы. Интеграция в VS требует БОЛЬШОЙ инфраструктуры, и interop, вероятно, вызовет головные боли. Существует несколько компаний, которые продают средства управления редактора форм окон, до которых Вы сцепляете свой синтаксический анализатор. С этим намного легче интегрировать, чем VS.

Я использовал бы Шиканье, я думаю, что это в настоящее время - один из самых гибких инструментов для создания DSL. Существует очень хорошая книга о предмете. Блоги Ayende и Rodrigo являются хорошим вдохновением также.

О IDE Вы могли расширить SharpDevelop, смотреть на это.

Стандартный инструмент для создания швов DSL, чтобы быть ANTLR - это - мощный лексический анализатор / парсер-генератор с большим количеством выходных языков для выхода компилятора. Это имеет бэкенды для C#, Java, C/C++, Python и т.д. (см. целевой список генерации кода), и позволяет Вам ввести пользовательский код в свой компилятор на Вашем выходном языке легко.

Существует также очень мощный IDE (ANTLRWorks) и много документации. (Проверьте Ссылку Defenitive ANTLR от Terrence Parr, автора ANTLR) Для Ссылок на том, кто еще использует его, посмотрите страницу Testimonlals.

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

Я в настоящее время использую компилятор, записанный с ANTLR для предварительной обработки нашего собственного DSL к выводу C/C++, и очень доволен им. Достаточно рекламы, необходимо попробовать его за себя :)развлекайтесь!

Система метапрограммирования JetBrains

Можно определить пользовательских редакторов языка и другие ограничения для любого нового языка, так, чтобы работа с теми DSLs стала действительно простой. Специалисты по проблемной области, которые не знакомы с традиционным программированием, могут легко работать в MPS со своими проблемно-ориентированными языками с помощью проблемно-ориентированной терминологии.

Я плохо знаком с ним, но OMeta походит на идеальный инструмент для разработки DSLs. Кажется, нет IDE вокруг этого, но хорошие новости - то, что "правила", которые можно записать в OMeta, очень читаемы. (И это имеет дело с левой рекурсией, которая очень прохладна.)

В настоящее время существуют реализации OMeta, по крайней мере, в JavaScript (очень увлекательны для меня) и Python, возможно, другие. Что касается C#, Jeff Moser работает над одним, о котором можно читать на его блоге и видеть в CodePlex.Удачи.

Ruby является большим языком для создания DSLs. Например, Грабли являются сценарием сборки DSL, записанный с Ruby.

С предстоящим IronRuby возможно записать сценарии, которые называют Ваш код C# непосредственно.

Вот некоторые статьи при записи DSLs в Ruby.

Если Вы хотите создать дружественный IDE, который редактирует DSLs, сделайте IDE полностью графическим, и скомпилируйте в объекты.NET (или используйте что-то как IronPython как язык связующего звена).

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

Так или иначе, если ряд классов.NET или объектов IronPython, которые создают посреднический код, не достаточно "человекочитаем", затем возможности, Вы хотите что-то более с защитой от ложных команд, чем грамматика.

Тем не менее, если Вы просто хотите создать простой язык, который программисты могут использовать для создания Бизнес-правил, не стесняйтесь использовать любое вышеупомянутое и делать синтаксис достаточно минималистическим для не необходимости в IDE Visual Studio.