Boo Interpreter Speed ​​- веб-приложение

Question

Я пробовал искать аналогичный вопрос, но не смог его найти.

У меня есть ASPNET1.1 веб-приложение, ориентированное на бизнес. И есть много правил, которые жестко закодированы в приложении.

Я хочу начать использовать Boo в качестве языка сценариев, который разработчики могут использовать для написания там некоторой логики (не для конечных пользователей).

Всякий раз, когда происходит изменение BL, я просто обновляю «файл сценария», развертываю сервер и все. Нет необходимости в компиляции. Это важно.

Поэтому у меня есть два вопроса:

1. Это только кажется CSScript и Boo поддержки NET1.1 и мне не нравится CSScript, потому что это требует ехя или скомпилированный DLL для каждого сценария. Правильно ли выбран Бу? Я хотел использовать JINT (NET2.0 +) или LUA (не смог найти способ импорта на C#).
2. Как быстро выполнить Boo? Я не хочу его компилировать (я знаю, что это быстро, так как это будет статический язык). Я хочу использовать только функцию Eval для интерпретатора Boo.

Кстати, бизнес-логика, которую я хочу выполнить, проста. Это должно быть только:

function(a, b) 
{ 
return a["Type"] == b["Type"]; 
} 

где a и b - просто Hashtables или DataRow. Поэтому мне действительно не нужен импорт системы и все такое.

Заранее спасибо

Answer 1

Я отбрасывая Boo, потому что несмотря на то, что я хотел использовать только метод Eval, Boo автоматически компилирует выражение и нагрузки, которые Ассамблея генерируемую в AppDomain.

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

Даже если я создаю внутренний AppDomain и запустил там скрипт, чтобы память была восстановлена.

Если я запускаю в том же AppDomain, память будет съедена и съедена, потому что эти новые сборки будут загружены и никогда не будут выгружены.

Так что я думаю, что ответ Рикардо на некоторых форумах никогда не предполагал, что язык Boo разрабатывается как язык CLR, но он превосходит весь «скриптовый» ореол, наложенный вокруг Boo.

Это большой бух для Boo :(

Я просто проверял LuaInterface 1.3.0 (последний, который поддерживает NET1.1) и имеет след нуля. Не создаются сборки и просто лучше вообще (больше javascript-like, no footprint и т. д.)

Я просто надеюсь, что версия 1.3.0 будет достаточно стабильной. В ближайшем будущем я не могу обновить свое приложение до NET2.0.

ВАЖНОЕ ОБНОВЛЕНИЕ: У LuaInterface и luanet было много утечек памяти !!!! В Я привязался напрямую к lua52.dll с использованием DllImport и используя в качестве основы следующий файл: https://simpleot.googlecode.com/svn-history/r32/SimpleOT/trunk/SimpleOT/Scripting/Lua.cs

Я использовал lua52, потому что он поддерживал VC++ 2003.