Язык сценариев для встраивания в приложения C# /. NET?
[На только аналогичный вопрос, который я могу найти, был дан ответ давно, и он содержит ссылку в основном на IronPython. Хочу рассмотреть и другие варианты]
У нас есть приложение для комплексного анализа данных, написанное на C#. Приложение должно предоставлять пользователям сложные средства настройки их задач анализа данных. В настоящее время мы используем смесь файлов конфигурации и таблиц Excel, чтобы указать это, но это становится громоздким, поэтому мы ищем язык сценариев для встраивания.
Какой самый простой язык сценариев для встраивания C# /. NET? Можно ли как-то встроить VBA аналогично Excel / Word? Или, может быть, используется JavaScript / Lua?
Излишне говорить, что во встроенных сценариях должно быть легко предоставить доступ к некоторым API и объектам из основного приложения.
Ответы 12
Бу возможно?
Чем он лучше IronPython?
@eliben: "лучше"? Чем может быть что-нибудь «лучше» IronPython? Это другое. Он имеет необязательную статическую типизацию и очень подходит для указания DSL, которые могут хорошо соответствовать вашему сценарию. См. ayende.com/Blog/archive/2007/12/17/The-Boo-Language.aspx
Да, но он довольно новый, неподдерживаемый и непонятный. Нет шансов получить по нему книгу, сообщество пользователей невелико, а библиотек немного. В конце концов, мне нужно «корпоративное» приложение, так что Бу не подойдет.
Книга: manning.com/rahien
Библиотеки: это язык .NET, поэтому все, что есть в мире .NET, принадлежит вам.
встраивание очень просто: boo.codehaus.org/Boo+as+an+embedded+scripting+language
@eliben: В чем Бу особенно «новенький»? Манифест Boo датируется ~ 2004 годом, что всего на год позже, чем IronPython. Если вам нужно что-то «лучше», чем IronPython, вы должны явно определить свои критерии. Вы сказали, что вам нужен вариант, отличный от IronPython. Я дал тебе одну.
Джон Скит - спасибо за это. Я как раз обсуждаю этот вариант. Надеюсь, это не звучит резко - я рад за ссылки
Я знаю, что вы просили технологию создания сценариев, но основная потребность - контроль кода для непрограммистов. Мы используем Правила ILOG для .Net, чтобы удовлетворить эту потребность.
Я знаю, что другой вопрос относится к IronPython, но я все еще чувствую, что он должен быть здесь, потому что я думаю, что это один из лучших вариантов.
Еще один отличный вариант - IronRuby. Основное различие, которое я вижу, было бы, если бы ваши разработчики / пользователи имели какой-либо опыт работы с Python или Ruby, который можно было бы перенести.
На самом деле, в конце концов, вашим лучшим вариантом будет язык, который легче всего адаптируется пользователями. Если они не примут это и не смогут работать более продуктивно, чем при старом методе, это не стоит усилий.
+1, по моему опыту, Python очень легко учить и изучать, и непрограммисты воспринимают его так же хорошо, как и опытные программисты.
Python легко изучить; использование классов .NET Framework в IronPython менее эффективно. Но это проблема, с которой вы столкнетесь с любым языком сценариев, который взаимодействует с фреймворком, и вы, вероятно, не захотите использовать тот, который этого не делает. Я использую IronPython и очень доволен результатом.
Lua великолепен! Lua отлично работает с .NET. Я написал сообщение в блоге о том, как начать встраивать Lua и C#, возможно, стоит проверить:
http://blog.apterainc.com/software/embedding-lua-and-c/
Фу! Я получаю 404 по вашей ссылке.
Вот почему stackoverflow требует, чтобы содержимое ссылки, относящейся к ответу, было включено в этот ответ (чтобы избежать мертвых ссылок).
А как насчет C#? Нет причин, по которым вы не можете позволить пользователю писать C#, а затем безопасно загружать его в другой домен приложений со всеми правильными ограничениями и мерами безопасности.
Нет, я думаю, C# слишком многословен и сложен для пользователей.
А как насчет JScript.NET или PowerShell
Я бы посмотрел только на XAML Windows Workflow. Вы можете повторно разместить конструктор и предоставить настраиваемые действия, которые можно перетаскивать и использовать для управления данными любым удобным для них способом. ОЧЕНЬ наглядно. В настоящее время я использую это в одном из своих приложений, и пользователям это нравится. Хотя для этого требуется небольшая кривая обучения, это намного меньше, чем у обычного языка сценариев, и люди, кажется, могут понять его довольно быстро, особенно те, кто имеет опыт использования блок-схем и Visio.
Это может быть очень полезным и удобным для пользователя, если требуемая настройка достаточно хорошо определена и легко параметризуется. В противном случае вы вернетесь к предоставлению языка сценариев.
Я согласен ... но именно поэтому вы создаете общие действия, чтобы обрабатывать столько различных процессов, сколько вам нужно. В этом случае действия заменяют отдельные языковые структуры ключевых слов, такие как if, while и т. д.
Я думаю, что использование C# через CodeDom - очень мощное решение.
Я бы также проголосовал за использование C# для написания ваших расширений. Если у вас нет веской причины, такой как существующая база пользователей, уже знакомых с python, ruby или boo, перевод на другой язык просто увеличивает сложность и стоимость обучения.
Есть много-много-много языки сценариев. Что лучше для вас, зависит от того, что вы пытаетесь сделать.
Вам следует проанализировать задачи, которые нужно выполнить вашим пользователям, обозначения, с которыми они уже знакомы, и выбрать существующий язык сценариев, который им соответствует. Вы не должны выбирать популярный язык сценариев, а затем заставлять ваше приложение и пользователей вписываться в него.
Были упомянуты Boo и IronPython, но не забывайте IronScheme, F# или любой из Другие языки, которые были перенесены на виртуальную машину CIL и имеют компиляцию / интерпретацию во время выполнения.
IronRuby с каждым днем выглядит лучше.
Вы проверяли ШЕЛК? Он был разработан для этой цели.