0

同様の質問を探してみましたが、見つかりませんでした。

ビジネス指向の ASPNET1.1 Web アプリケーションがあります。また、アプリケーションにハードコーディングされている多くのルールがあります。

Boo をスクリプト言語として使い始めたいと思っています。これは、開発者が (最終ユーザーではなく) そこにロジックを書くために使用できます。

BL の変更が行われるたびに、「スクリプト ファイル」を更新し、サーバーにデプロイするだけです。コンパイルの必要はありません。これは重要。

だから私は2つの質問があります：

  1. CS-Script と Boo だけが NET1.1 をサポートしているようですが、スクリプトごとに exe またはコンパイル済みの dll が必要なため、CSScript は好きではありません。ブーは正しい選択ですか？JINT (NET2.0+) または LUA を使用したかった (C# にインポートする方法が見つからなかった)。
  2. ブーを実行するのはどれくらい速いですか? 私はそれをコンパイルしたくありません (静的言語になるので、これが高速であることはわかっています)。Boo インタープリターの Eval 関数のみを使用したい。

ちなみに、実行したいビジネスロジックは単純です。それは次のようなものでなければなりません：

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

ここで、a と b は単に Hashtables または DataRow です。したがって、実際にはシステムのインポートなどは必要ありません。

前もって感謝します

4

1 に答える 1

0

Boo を破棄するのは、Eval メソッドのみを使用したかったにもかかわらず、Boo が式を自動的にコンパイルし、Assembly が生成した AppDomain にロードするためです。

私はASPNET1.1と大規模なWebアプリケーション（数千人のユーザー）で実行しているため、効率的でも高速でもありません。

内部 AppDomain を作成してそこでスクリプトを実行しても、メモリが復元されます。

同じ AppDomain で実行すると、これらの新しいアセンブリが読み込まれ、アンロードされないため、メモリがどんどん消費されます。

したがって、いくつかのフォーラムでの Ricardo の回答から推測すると、それは Boo 言語が CLR 言語として設計されることを意図したものではありませんでしたが、Boo の周りに置かれた「スクリプト」ハロー全体を打ち負かしています。

これはブーにとって大きなブーイングです:(

LuaInterface 1.3.0 (NET1.1 をサポートする最後のバージョン) をテストしたところ、フットプリントはゼロです。アセンブリは作成されず、一般的に単純に優れています (より JavaScript に似ている、フットプリントがないなど)。

バージョン 1.3.0 が十分に安定していることを願っています。近い将来、アプリを NET2.0 にアップグレードする方法はありません。

重要な更新: LuaInterface と luanet には大量のメモリ リークがありました!!!! 代わりに、DllImport を使用し、次のファイルをベースとして使用して、lua52.dll に直接リンクしました 。

VC++2003に対応していたのでlua52を使いました。

于 2012-05-11T19:05:53.413 に答える