话说，如今不在客户端使用JavaScript代码才是稀奇事儿。由于Web应用的体验越来越丰富，客户端用JavaScript实现的逻辑也越来越多，这造成的结果就是某些几乎一致的逻辑需要在客户端和服务器端各实现一遍。这违反了DRY原则，不容易维护。幸运的是，我们可以在服务器端执行JavaScript代码，谁让JavaScript傍上了这无比霸道的浏览器平台呢？

例如，如今在客户端使用JavaScript进行验证已经是个标准，它可以有效避免用户在正常情况下提交错误的数据，增强用户体验。当然，服务器端的验证是必不可少的，因为这才是“安全性”的体现。有些解决方案，会在服务器端提供有限的验证种类，然后在客户端生成JavaScript代码，并辅以服务器端的验证框架。这种做法可以追溯到ASP.NET 1.x上的Validator控件，但这显然会有扩展性，灵活性上的限制，因此我更倾向于在服务器端执行JavaScript代码。

例如，要检查用户名是否合法，我们可能会写这样的JavaScript代码：

var checkName = function (name) { return /^w{3,10}$/.test(name); }

这在客户端验证自然没有任何问题，服务器端就要借助一些JavaScript执行引擎了。在.NET平台上有例如比较新的IronJS项目，这是个基于DLR的JavaScript执行引擎，十分重视性能，从作者博客上的评测结果来看，甚至领先于以速度见长的V8。可惜的是，IronJS还没有完整实现ECMAScript 3.0，还缺少一些重要功能，例如正则表达式。

Jint是一个.NET平台上较早的JavaScript执行引擎，因此与DLR关系不大，因此可能不太容易与IronPython，IronRuby等语言进行互操作。用它来执行一些简单的JavaScript脚本不成问题，例如上面的代码：

var jint = new Jint.JintEngine();
jint.Run(@"var checkName = function(name) { return /^w{3,10}$/.test(name); }");

Console.WriteLine(jint.CallFunction("checkName", "jeffz")); // TrueConsole.WriteLine(jint.CallFunction("checkName", "hello world")); // False

只可惜，在实际使用中，Jint不支持多线程的环境，即我们无法在多个线程下同时调用jint的CallFunction方法，但是如果每次都重新Run一遍JavaScript代码，也会带来较多的性能开销。其实要解决这个问题也并不困难，构造一个对象池即可，.NET 4中提供了并行容器(如ConcurrentStack，ConcurrentQueue)，实现一个简单的对象池可谓不费吹灰之力。

这方面Jurassic的表现要好的多，这是一个构建于.NET 4.0的JavaScript执行引擎：

var engine = new Jurassic.ScriptEngine();
engine.Evaluate(@"var checkName = function(name) { return /^w{3,10}$/.test(name); }");

Console.WriteLine(engine.CallGlobalFunction<bool>("checkName", "jeffz"));
Console.WriteLine(engine.CallGlobalFunction<bool>("checkName", "hello world"));

此外，从Benchmark上来看，Jurassic性能也比Jint有所提高，但还是远远落后于V8，甚至IE 8里的JavaScript引擎。而且，它还提供了一个基于Silverlight控制台，您可以在浏览器里把玩一番。

令人感到意外的是，Jint和Jurassic作为JavaScript执行引擎都有一些严重的问题，那便是不能正确运行showdown.js(JavaScript实现的Markdown转化器)——虽然我并没有发现showdown.js中有过于复杂的内容，基本就是些字符串操作吧。原本我还想把它们用在mono中，既然如此也就不做进一步尝试了。不过，经过简单的实验，Jurassic似乎使用了mono 2.8中尚不支持的接口，但也有可能只是Jurassic控制台中的问题。

有趣的是，.NET平台下最靠谱的JavaScript执行引擎居然是Rhino JavaScript，最近一次发布是在2009年3月，不过实现的十分完整。要说缺点，可能就是使用起来比较麻烦，还有，这是个Java项目。

嗯，我没有开玩笑，我们完全可以在.NET平台下使用Rhino JavaScript：

var cx = Context.enter();
try{
    var scope = cx.initStandardObjects();
    cx.evaluateString(scope, @"var checkName = function(name) { return /^w{3,10}$/.test(name); }", "checkName.js", 1, null);
    var func = (Function)scope.get("checkName", scope);

    Console.WriteLine(Context.toString(func.call(cx, scope, scope, "jeffz")));
    Console.WriteLine(Context.toString(func.call(cx, scope, scope, "hello world"));
}
finally 
{
    Context.exit();
}

因为我们有IKVM.NET。mono等.NET开源社区上有大量宝藏，就看您能利用多少了。我用ikvmc把js.jar转化为RhinoJs.dll之后就可以直接使用，效果很好，对调试也有很好的支持(如果JavaScript执行时出现了错误，则VS会直接带您至出错的那行)。性能也是比较令人满意的，在我的Mac OSX上安装的Ubuntu Server 10.10虚拟机，单线程转化并过滤博客上最近的3800条评论，大约耗时20秒。试验时Host上还开着一个Windows 7虚拟机，还有大量浏览器等应用程序，并不十分空闲。

您可能知道，我的博客目前是基于mono 2.6的，其中比较有特色的地方便是评论功能了，我使用Markdown标记，并提供了实时的预览功能，这自然需要在客户端解释Markdown标记，并进行过滤。目前，我还在服务器使用了C#实现的Markdown转化器及过滤逻辑，但在某些特殊情况下结果会有所不同，且需要维护两套代码。不久以后，我会将把博客升级为ASP.NET 4.0及mono 2.8(C# 4.0的dynamic特性在某些情况下的确比较方便)，并且在服务器端使用IKVM.NET + Rhino JavaScript执行相同转化代码。从效果上来看还是十分令人满意的。

值得一提的是，其实在.NET平台上还有一个基于DLR的JavaScript执行引擎，是为RemObjects Script for .NET，据称也支持mono。只可惜它并不是开源产品(不过公开了源代码)，且授权协议要求我们最多在5台机器上安装代码，且只供我们自己使用，于是我就没有对它有关注太多了。