Какую технологию использовать при создании DSL для механизма правил?
https://stackoverflow.com/questions/545937
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Какую технологию вы бы порекомендовали для создания DSL для Бизнес-правила и блок приложения проверки для .NET?И почему?
Архитектура фреймворка создана и проверена на производстве.Я просто хочу создать процессор .NET для преобразования удобочитаемых правил в скомпилированные реализации правил.
Варианты, которые мне известны:
- Используйте конвейер компиляции .NET Бу
- Используйте компоновщики парсеров, входящие в состав F# — ФсЛекс и ФсЯкк
К сожалению, ни один из этих подходов не дает ничего для создания более или менее дружественной IDE для редактирования DSL, учитывая синтаксис DSL (который будет развиваться).
Есть идеи или подсказки?
Решение
Платформа Microsoft для разработки приложений следующего поколения под кодовым названием Осло
Облегчает людям запись вещей так, чтобы это имело смысл для проблемной области, над которой они работают.
Осло, похоже, состоит из инструмента визуального проектирования под названием «Quadrant», языка моделирования под названием «M» и репозитория «Осло» (базы данных SQL Server), в котором хранятся правила.
Итак, если я правильно прочитал, вы могли бы определить язык моделирования на M, использовать Quadrant для определения и редактирования правил проверки, используя свой собственный язык моделирования, и написать приложение, которое использует репозиторий Осло, генерируя ваши бизнес-правила и приложение проверки. Блок для .NET.
Другие советы
Графический язык для бизнес-правил — не лучшая идея.Я бы избегал этого. В бизнес-правилах много проверок if и циклов, которые плохо визуализируются.
Гораздо лучше использовать текстовый язык для описания бизнес-правил.
Чтобы получить феноменальный пользовательский опыт редактирования кода, вам необходимо:
- Парсер с хорошим восстановлением ошибок
- Возможность выполнять инкрементную перекомпиляцию.
Хорошее восстановление ошибок позволяет эффективно определять намерения программиста по синтаксически неполным конструкциям.Это крайне важно для реализации интеллекта.
Возможность инкрементной перекомпиляции дает вам возможность выполнять эффективную фоновую компиляцию в ответ на изменения пользователя.
Самый простой способ добиться хорошего восстановления ошибок — написать парсер вручную.Таким образом, вы можете использовать любой объем предпросмотра или алгоритмические правила, чтобы выяснить, что делать при наличии синтаксических ошибок.
Когда вы используете генератор синтаксического анализатора для создания своего парсера, вы теряете большую гибкость в работе с синтаксическими ошибками.Эта гибкость и отличает хороший разведывательный опыт от дрянного.Итак, я рекомендую вам просто написать это вручную, используя рекурсивный спуск.
Для реализации эффективной перекомпиляции необходимо уметь:1) Правильно разбить семантический анализ на этапы (для чего-то вроде C# это будет так:сначала создайте пространство имен и введите символы, затем разрешите операторы using, затем разрешите базовые классы и т. д.).2) Возможность построения фазово-сознательного графика зависимостей 3) Алгоритмы обработки графа зависимостей и аннулирования его частей в ответ на пользовательские правки
Для полноценного языка программирования реализация перекомпиляции может оказаться очень сложной.В вашем случае, поскольку вы описываете бизнес-правила, для вас это может быть намного проще (или, если компиляция достаточно быстрая, вам это может даже не понадобиться).
Итак, я бы начал с парсера, а затем построил бы на его основе интеллект.
Если вы можете избежать интеграции с VS, я бы это сделал.Интеграция в VS требует МНОГО сантехнических работ, и взаимодействие может вызвать головную боль.Есть несколько компаний, которые продают элементы управления редактора форм Windows, к которым вы можете подключить свой синтаксический анализатор.С ним гораздо проще интегрироваться, чем с VS.
Другая, возможно, интересная альтернатива — использование кавычек F#.
Кавычки позволяют рассматривать часть программы как данные, поэтому вы можете получить AST, проанализировать его и перевести на другой язык или выполнить каким-либо нестандартным способом.Благодаря гибкости F# вы сможете выражать множество вещей, поэтому вам придется разработать внутреннюю библиотеку F# DSL/комбинатор для описания правил и транслятор/интерпретатор цитат F# для их выполнения.
Не знаю, как может выглядеть бизнес-правило, но вы могли бы написать что-то вроде этого:
let rule = <@
if (exists customer having validEmail) then success
else require whatever
@>
Введение в эту тему я написал в своем блоге.К сожалению, в CTP F# произошли некоторые большие изменения, и я еще не обновил исходный код, но это должно дать вам хорошее представление о возможностях и ограничениях этого подхода.
- Примеры котировок F# на CodePlex - ТомасП.Нет
Хорошим примером DSL является структура модульного тестирования F#:
- Анонс FsTest — тестового DSL для F# - Мэтью Подвысоцкий
[РЕДАКТИРОВАТЬ]Просто чтобы прояснить, почему я считаю, что это может быть хорошим подходом:
- Если вы используете Visual Studio для редактирования DSL (и вы можете бесплатно использовать версию Shell с установленным F#), вы бесплатно получите очень хорошие возможности редактирования.Не только подсветка синтаксиса, но и IntelliSense, который предложит возможные конструкции, а также фоновую проверку типов, которая служит средством проверки «грамматики» для вашего DSL.
- По сравнению с другими подходами этот, пожалуй, один из самых простых в реализации.
- Единственное ограничение заключается в том, что вы ограничены синтаксисом F#.Однако разработать собственный язык действительно сложно, так что, возможно, это не так уж и плохо.Особенно учитывая гибкость F#.
[/РЕДАКТИРОВАТЬ]
Надеюсь это поможет!
Я бы использовал Boo, думаю, на данный момент это один из самых гибких инструментов для создания DSL.Есть очень хорошая книга о предмете. Айенде и Родриго блоги тоже являются хорошим источником вдохновения.
Что касается IDE, вы можете расширить SharpDevelop, Взгляни на этот.
Стандартный инструмент для построения швов DSL. АНТЛР - это мощный генератор лексеров/парсеров с множеством целевых языков для вывода компилятора.Он имеет бэкэнды для C#, Java, C/C++, Python и т. д.(см. цели генерации кода list) и позволяет легко вставлять собственный код в компилятор на целевом языке.
Также имеется очень мощная IDE (ANTLRWorks) и множество документации.(Проверить Полная ссылка на ANTLR от Терренса Парра, автора ANTLR) Ссылки на то, кто еще его использует, см. Отзывы страница.
Вам по-прежнему придется выполнять большую часть работы с IDE самостоятельно, но это должно быть намного проще, учитывая надежную структуру компилятора, которую вы получите от ANTLR.Это должно быть так для большинства решений, опубликованных здесь...
В настоящее время я использую компилятор, написанный на ANTLR, для предварительной обработки нашего собственного вывода DSL на C/C++ и очень доволен этим.Хватит рекламы, попробуйте сами :) Удачи!
JetBrains Система метапрограммирования
Вы можете определить собственные языковые редакторы и другие ограничения для любого нового языка, чтобы работа с этими DSL стала действительно простой.Эксперты в предметной области, не знакомые с традиционным программированием, могут легко работать в MPS со своими предметными языками, используя специфичную для предметной области терминологию.
Я новичок в этом, но ОМета кажется идеальным инструментом для разработки DSL.Кажется, для этого не существует IDE, но хорошая новость заключается в том, что «правила», которые можно написать в OMeta, очень читабельны.(И речь идет о левой рекурсии, что очень круто.)
В настоящее время существуют реализации OMeta, по крайней мере, на Javascript (мне очень интересно) и Python, а возможно, и на других языках.Что касается С#, Джефф Мозер работает над одним, о котором вы можете прочитать на его блог и посмотреть в КодПлекс .Удачи.
Boo + OMeta = Boo.OMeta.Parser
В настоящее время парсер находится в стадии разработки, но его уже можно использовать для создания сложных внешних DSL.OMeta — мощный инструмент, который позволяет программистам легко реализовывать лексические анализаторы и парсеры.Расширяемая архитектура конвейера компилятора Boo позволяет заменить стандартный Boo.Parser на Boo.OMeta.Parser.Его можно использовать для расширения синтаксиса Boo практически любым синтаксисом.Пример можно найти здесь.
Мой проект мета# пытается решить эту проблему.
Если вы хотите создать дружественную IDE, которая редактирует DSL, сделайте IDE полностью графической и скомпилируйте ее в объекты .NET (или используйте что-то вроде IronPython в качестве связующего языка).
Если правила достаточно просты, вы можете реализовать всю структуру правил графически.Если правила достаточно сложны, «удобочитаемость человеком» становится недостижимой целью.
В любом случае, если набор классов .NET или объектов IronPython, создающих промежуточный код, недостаточно «читабелен для человека», то, скорее всего, вам нужно что-то более надежное, чем грамматика.
Тем не менее, если вы просто хотите создать простой язык, который программисты смогут использовать для создания бизнес-правил, не стесняйтесь использовать любое из вышеперечисленного и сделайте синтаксис достаточно минималистичным, чтобы не нуждаться в интегрированной среде разработки Visual Studio.
Ruby — отличный язык для создания DSL.Например Грабли — это сценарий сборки DSL, написанный на Ruby.
С предстоящим ЖелезоРубин можно писать сценарии, которые напрямую вызывают ваш код C#.
