如何用好IronPython

翻看了一下Tutorials，发现和以前的内容差不多，按照Tutorials中的方法尝试了一下在C#中嵌入IronPython 代码，发现还很不错，最起码可行，虽然速度肯定没有用C#直接写出来的快（因为IronPython需要动态编译的缘故）。

好的，现在我们拥有了一项较稳定的可以投入使用的新技术了，但是如果没有市场，那么这个新技术是不能够生存的，所以我左思右想 IronPython在企业级开发中到底占了什么地位（因为我是做企业级开发的:)），有何等优势呢？通过分析现有IronPython的特征，我得到了一个结论，那就是它比较适合做脚本引擎或者简单的客户端。以下是我分析的IronPython的一些特征：

1. Python的语法，灵活性相当的高！
2. 与.NET Framework的交互实现的非常的好，现在用Python的语法也可以用.NET的类库了。
3. 在其他.NET语言中可以通过引用IronPython.dll来执行IronPython文件并且可以实现内存共享（在同一AppDomain中）。
4. 纯IronPython程序启动非常慢。
5. 由于IronPython的特殊性，它所编译出来的程序集中的成员并非你所想象的，所以不能够由其他程序集直接引用使用。这主要还是因为Python是一种动态类型语言，所以无法在编译时给予合适的静态类型（唯一合适的就是System.Object）。另外为了与CPython保持兼容性，IronPython也是以module为单位进行group的，也就是一个module被编译成一个类，这个module中的所有成员，包括class都被当作成员编译在这个类中。

基于以上一些IronPython现有的特征来看，我觉得它更适合使用.NET 程序集，而非为.NET程序提供功能（虽然也是可行的，也是我希望的），所以我建议将IronPython用作客户端以及脚本引擎一类的用途上，因为这类程序是属于consumer类的，它们使用现成的API，但是它们不为其他人提供新的API。

如何用IronPython为.NET程序提供API

读者可能会说我自相矛盾，刚刚才说过IronPython不适合用来提供API，怎么现在又提起这件事来了呢（唉，人本身就是一种很矛盾的生物）？！其实就像上面我在括号中提及的，利用IronPython的交互能力与语言的灵活性为我的.NET程序提供简化的解决方案是我的期望，虽然速度方面还不尽人意，但优化的空间永远都是存在的，我相信随着时间的推移IronPython会在性能方面做的更出色（从这方面来看我是个乐观主义者:D）。

为了简化主程序与IronPython文件的交互与维护难度，我决定将IronPython文件作为服务（service）来看待，IronPython所提供的每一个API就是一个独立的服务，每次需要使用这个服务的时候我只需向它发送相应的消息（message）即可，而它，会返回给我一个回应（response）如果有必要的话。我觉得这样做比较符合目前的SOA潮流。（如果你还不知道SOA是什么的话，一句话告诉你，它是一种企业级集成手段）

我的做法很简单，只是初步实现了一个对IronPython文件调用的封装，示例如下。

 List<int> a = new List<int>();
 a.Add(1);
 a.Add(2);
 a.Add(3);

 List<int> b = new List<int>();
 b.Add(4);
 b.Add(5);
 b.Add(6);

 PyFacade<IList<IList<object>>> py =
    new PyFacade<IList<IList<object>>>();
 py.PythonFile = "mayorThenTen.py";
 py.Arguments.Add("listA", a);
 py.Arguments.Add("listB", b);
 py.Execute();

 foreach (IList<object> tuple in py.Result) {
    Console.Write(tuple[0]);
    Console.Write(", ");
    Console.Write(tuple[1]);
    Console.WriteLine();
 }

PyFacade的代码如下。

using System;
using System.Collections.Generic;

using IronPython.Hosting;

namespace Cavingdeep.Python {
   public class PyFacade<T> {
      public const string ResultVariableName = "_result_";

      private PythonEngine engine = new PythonEngine();

      private string pythonFile;
      private Result<T> result = new Result<T>();
      private IDictionary<string,object> args =
         new Dictionary<string,object>();

      public string PythonFile {
         get {return this.pythonFile;}
         set {this.pythonFile = value;}
      }

      public T Result {
         get {return this.result.Value;}
      }

      public IDictionary<string,object> Arguments {
         get {return this.args;}
      }

      public void Execute() {
         engine.Globals[ResultVariableName] = this.result;

         foreach (KeyValuePair<string,object> arg in this.args) {
            engine.Globals[arg.Key] = arg.Value;
         }

         engine.ExecuteFile(this.pythonFile);
      }
   }
}

Result的代码如下。

using System;

namespace Cavingdeep.Python {
   public class Result<T> {
      public T Value;
   }
}

mayorThenTen.py的代码如下，这是这个示例中用到的IronPython文件。

def mayorThenTen(a, b):
   return [(x, y) for x in a for y in b if x + y > 5]

if globals().has_key('_result_'):
   _result_.Value = mayorThenTen(listA, listB)

这里的这个PyFacade是个比较通用的与IronPython交互的接口类，在真正的应用中建议用强类型模式（强类型设计实践）加以封装以得到type safety等好处。

关于PyFacade是如何与IronPython文件交互一题，简单地说就是通过那个_result_变量，它会在IronPython文件中被赋值，这个值是外界可见的，也就是说IronPython文件的执行与当前程序是在一个AppDomain中的。有关这类知识感兴趣的读者可以去研究一下动态编译、加载与程序域（AppDomain）等知识。

当a的setx方法被调用时，会被“拦截”，先输出pre...然后是原始setx的方法调用，最后输出post...

看到那个__metaclass__变量了吗？如果你赋给它另外一个metaclass的话它会产生其他效应（我这里做的是 logging，其他的可能有例如timing、access control、transaction, etc.），这是魔法！^_^ 最魔力十足的地方是我甚至可以把一个metaclass传进模块中去，给__metaclass__动态的赋值（赋metaclass），这意味着我可以通过meta-programming动态的改变我程序的逻辑，或者不需要改动原有代码即可添加新功能（或修改）等特点！

整个演示就当作抛砖引玉吧，代码我就不细讲了，因为概念太复杂了，不是一两句能说得明白的。有兴趣的朋友可以研究一下Python。; -)

该不该使用Generics实现Abstract Factory？

我的意见是不应该，理由如下：

1. 具体创建对象的时候，也就是在ConcreteFactory中，不是所有情况都是简单地一个new操作就算是创造对象了，就像它的名字所示那样，具体对象具体操作，这里不能泛化，一定要根据具体类型来实现对象创建。
2. 就像许多人提到的，到底用多少个type variable才算合适呢？AbstractFactory<A, B>, AbstractFactory<A, B, C> ??? 简单地说，Abstract Factory是不能够定量的，目前.NET与Java的泛型都不能实现这点。

Java的泛型真的那么弱吗？如果要实现定量的Abstract Factory真的很难吗？

我的答案是否，实际上，我觉得用Java的语法无论在实现上的阅读与易用性都要比.NET的语法强。下面是我给出的Abstract Factory的实现，虽然我说过，用Generics实现Abstract Factory并不合适。

interface Processor {}

interface Ram {}

class PentiumProcessor implements Processor {}

class DDRRam implements Ram {}

interface AbstractFactory<PA, PB> {
   PA createA();
   PB createB();
}

class IntelFactory implements AbstractFactory<PentiumProcessor, DDRRam> {
   public PentiumProcessor createA() {
      // 一切特化且可在这里实现。
      return new PentiumProcessor();
   }

   public DDRRam createB() {
      // 一切特化且可在这里实现。
      return new DDRRam();
   }
}

// 使用
AbstractFactory<? extends Processor, ? extends Ram> factory =
   new IntelFactory();
      
Processor processor = factory.createA();
Ram ram = factory.createB();

以上代码并没有运用不必要的TypeToken，而且也没有实例化时特化的问题，但是仍然没有解决Abstract Factory的量的问题。可以看出，这段代码非常的简洁，我觉得这段代码真正突出了Generics的优点：泛化类型，而没有做不应该做的过多的事情（比如泛化本来应该是特化的东西）。

注意Java的Generics语法是可以使用wildcard的（?），这是.NET所没有的。wildcard的特点之一就是能够在变量声明中使用，这是很重要的一大特色。

我这里简单描述一下现有功能，有兴趣的朋友请自行下载。

1. 使用简便切容易扩展的模板引擎。
2. 提供基于ASP语法的模板语言，简单易上手。
3. 扩展ASP的DTL（Dynamic Template Language）模板语言。现在写模板终于变得简单易维护了！
4. 内置Dcg对象，提供模板自身信息。
5. 完美自控资源清理，不会在您的目标系统上留下任何痕迹。
6. 安全的动态模板执行，运行DCG动态模板不会危及到您的系统，您尽可放心运行从第三方获得的DCG动态模板，因为DCG模板的运行权限要比Internet程序还要低。
7. 调试支持，开启调试后您将可以获得详细到行与列的错误提示信息。
8. 最后但却很重要的一项，DCG很快并且内存占用很优化，您尽可以放心的在你的程序中使用大量DCG动态模板。

我会在今后的一些时日中仔细描述每一个功能以及使用，同时我会告诉你它们能给你带来什么样的价值。

http://dcg.tigris.org

有需要的朋友们赶快自取吧。

《改进ASP语法打造更高效的模板语言》

《改进ASP语法打造更高效的模板语言II》

项目首页
http://dcg.tigris.org

文档页
http://dcg.tigris.org/doc.html

另外模板引擎的使用帮助也已经被写在了SDK帮助中，你可以通过获取最新的源代码获得，获取后用NAnt编译生成文档。如果在使用上有什么问题的话请通过此Blog与我联系。

让我们来看一个例子，假如我想输出以下内容：

int[] numbers = new int[] { 1, 2, 3, 4, 5 };

注意空格哦！这里的动态部分就是从1到5的这部分。模板要怎样写呢？可以这样：

int[] numbers = new int[] { <%
for (int i = 1; i <= 5; i++) {
   if (i < 5) {
      <%!
      <%=i%>, 
      !%>
   } else {
      <%!
      <%=i%>
      !%>
   }
}
%> };

int[] numbers = new int[] { <%=template1=%> };

<%# template1
for (int i = 1; i <= 5; i++) {
   if (i < 5) {
      <%!
      <%=i%>, 
      !%>
   } else {
      <%!
      <%=i%>
      !%>
   }
}
#%>

呵呵，不错，就是这个样子，这就是我想要的。嗯，<%# templateName #%>就是所谓的模板标签，它定义了一个动态模板，<%=templateName=%>就是模板引用，将被引用的模板结果输出到引用位置上。

这下清晰多了，而且模板可以被多个地方引用，达到一定程度上的可重用性。这套机制酷似XSLT中的template标签，不过没有模板参数等的定义。也许你会问：“那我可以传参数给模板标签吗？”可以，不过准确的说不是你手动传，是自动传的。换句话说，模板引用是一个Closure，模板标签中的内容在运行时会自动获得所有模板引用当前的上下文。比如如下示例：

<%# t1
   if (var) {
      <%!
      OK
      !%>
   } else {
      <%!
      oh, no
      !%>
   }
#%>
<%
   bool var = true;
   <%!
   First time call's result is <%=t1=%>.
   
   !%>
   
   var = false;
   <%!
   Second time call's result is <%=t1=%>.
   !%>
%>

输出为：
First time call's result is OK.
Second time call's result is oh, no.

好了，这篇的内容就介绍完了，不知道我所描述的这两大DTL语法有没有引起你的足够兴趣，再次说明一下，如果你已经感兴趣了的话，可以自己下载试一下哦。在《改进ASP语法打造更高效的模板语言》一篇中有相关链接。

Hello <%=employee.Name%>.

如何将静态与动态这两部分很好的混合在一个模板中一直是动态模板的易用性关键，比如如果我想输出从1到5，以逗号分隔这样的文字时我可以用以下写法：

<%
int length = 5;
%>
<%
for (int i = 1; i <= length; i++) {
   if (i < length) {
      %><%=i%>, <%
   } else {
      %><%=i%><%
   }
}
%>

输出为: 1, 2, 3, 4, 5

我们可以通过指定length变量来调节到底输出多少个数字，这就是动态模板的优势：含有动态代码。在这个例子中，我们将动态部分作为阅读主体，将静态部分作为辅助，这样可以写出来的模板才是可读的。但问题是以上ASP语法对初看ASP的人来说实在不习惯，因为ASP语法中是不可以在动态代码中嵌套静态文字的，所以我们才需要调整动态标签的位置，使整体看起来像是动态部分为主体，静态部分为辅助一样。

实际情况中，有时以静态部分为主看的要更清晰些，有时以动态部分为主看的更清晰些，没有绝对的情况。在这个比较简单的例子中ASP语法的可读性还不算太差，但是如果换个稍微复杂点的你就会觉得ASP语法写出来的模板几乎无法阅读。示例如下：

根据不同情况，我要输出：

情况1
void Foo() {
   string name1;
   // Do the right job
}

情况2
void Foo() {
   // Erase your hard disk
}

ASP语法的动态模板
void Foo() {
   <%
   if (case1) {
      %>string name1;
   // Do the right job<%
   } else {
      %>// Erase your hard disk<%
   }
   %>
}

就像上面例子中你所看到的，ASP语法的可读性很差，尤其当我有一个动态部分中嵌套静态部分，而被嵌套的静态部分中又嵌套有动态部分这样的情况下尤为突出。那么能不能有一种语法可以让我做到静态与动态之间的嵌套呢？回答是肯定的！

DCG (Dynamic Code Generator) 是我在去年开始的一个个人项目，简单地说，它就是一个提供了动态模板引擎的dll。1.x版本采用了ASP语法作为模板语言，并且提供了一些相关使用工具。在2.0版本中，我的目标是更强更易扩展的引擎与更易使用与阅读的模板语言。现很荣幸地告诉大家，我于昨天发布了DCG 2.0的Alpha版本，实现了我的初期目标，更强更易扩展的引擎，更易使用的模板语言：DTL。

DTL是基于ASP语法的一个语法扩展，完全兼容ASP。刚刚我们谈到，是否可以在静态于动态部分之前嵌套的问题，现在让我们来看看使用DTL是如何写上面那个示例的。

DTL语法的动态模板
void Foo() {
   <%
   if (case1) {
      <%!
      string name1;
      // Do the right job
      !%>
   } else {
      <%!
      // Erase your hard disk
      !%>
   }
   %>
}

<%! !%>标签是用来在一个动态标签内标明一段静态文字。注意静态内容的每一行开始都是与<%!标签对齐的，当输出时，结果会输出到<%!标签所属的<%标签的位置去。

现在有了静态标签，我们就可以随意的做嵌套了，如：

<%
if (condition) {
   <%!
   Content is:
   <%
   if (condition2) {
      <%!
      Content1.
      !%>
   } else {
      <%!
      Content2.
      !%>
   }
   %>
   !%>
}
%>

这可要比等价的ASP写出来的好看多了，最重要的是在编写模板的过程中利用DTL很直观，不会因为ASP语法的限制打断你的思路，从而提高你的效率，减少你的头疼率、压力，保护你的健康！:D

DTL还有一项语法增强，不过我会留到在下篇Blog中讲解，敬请关注！

如果你对此很感兴趣，想自己试验一下的话那么还等什么，赶快去下载Alpha版本吧，任何反馈都是受欢迎的。^_^

项目首页
http://dcg.tigris.org

二进制下载页面
http://dcg.tigris.org/servlets/ProjectDocumentList

源代码获取方式

建议使用TortoiseSVN获取：

Repository src dir
http://dcg.tigris.org/svn/dcg/trunk
用户名
guest
密码
guest

目前还没有充分的整理文档，使用请参考单元测试项目中的测试用例，另外请看生成的SDK文档，如果你获取源码编译，可以用NAnt使用项目中的default.build编译，你可能需要在这个文件中手动设置一下编译相关工具的路径。任何使用问题请用此Blog与我联系，任何bug或建议请使用项目首页中的Issue Tracker（可能需要你在Tigris注册，Tigris是一个面向开发人员的开源平台）。

DCG的license为LGPL，请尊重软件，尊重license！

• 数据载体
• 编程语言
• 文档语言

以上是一部分XML适用的领域，但绝对不是全部。也许你会问，难道XML是变形金刚吗？怎么可以变成这么多种不同领域的东西来？是，XML就像一个训练有素的军人，用不同的武器武装就可以胜任不同的岗位，管它是陆军、海军还是空军。这是怎么回事呢？我这里所提到的武器，就是X系列的其他技术，如XSLT，XPath等，用它们来武装XML就可以达到胜任多个岗位的能力。请看以下图解：

看到了吧，XML的威力！这里再分别提一下目前这些XML技术的使用案例：

• Ant, NAnt：以XML为语言形式，制作了基于target, task的任务编程语言。这里之所以选择XML而不是重新设计一种语言是为了降低编译器编写的成本。

• SOAP：用XML为Web Service定制的一套通信协议，目前大多数XML Web Service都在使用。

• 配置文件：目前大多数项目都选择XML作为自己的配置文件格式，可以看作是数据载体的一种。

• 支持XML的数据库：这些数据库可以将XML作为一种特殊的字段类型，可以直接在这个字段中使用XPath、XQuery检索数据，使XML成为了一种类似于数据库的数据载体。

• DocBook：它定制了多种schema，以XML作为文档载体，然后通过各种其他手段包括DOM、XSLT、XSL-FO等对XML文档进行格式化并最终展现。是一个将XML作为文档语言的案例。

其他案例还有很多，如果你还没有用到XML，那还等什么？难道说你真的不需要它吗？！请再考虑一遍！

• 时间的节省，X系列的所有理论伴有框架、工具等的支持，这些都是现成的，如果我采用XML，那么我立刻就可以拥有这些能力，包括XML的读取、书写，XML的格式验证（XSD），数据、结构的转换（通过XSLT），数据的检索（XPath）等等。如果不采用XML，那么这些我都需要自行实现。

• 研发成本，如果一个方案不采用XML，那么自行实现的技术风险就要比采用XML的大（除非技术实力真的很强），因为XML本身是可以很好的扩展并且是有先例可以借鉴的，但自行实现就没有这些优势了。

• 兼容性与扩展性，如果采用XML，会更方便的兼容第三方的解决方案，目前XML是一项被广泛采纳的标准，大多数组织都会选择在XML的基础上开发其他标准，如工作流的XPDL, Wf-XML，e-Commerce中的RosettaNet等。此外，你还可以通过XSLT在不同的标准间进行转换，能做到什么，就看你的想象力了。如果可以在对第三方的支持上有效快速的兼容、集成，那么无疑是对维护成本的一大笔节省。

最后再提一个XML的强项，也是比较有前途的应用，Mapping！XML结构上的高度灵活性与众多的辅助技术决定了它，也许是最好的mapping选择。我可以自由的在不同的数据源之间做映射，如下图所示：

 1IDbHelper helper = new SqliteHelper(this.connection);
 2
 3IDbCommand insertCommand = helper.BuildCommand(
 4   "INSERT INTO Test VALUES(NULL, @num, @r_date, @data)",
 5   1, DateTime.Now, new byte[0]);
 6
 7SQLiteConnection con = new SQLiteConnection();
 8con.ConnectionString = this.connection.ConnectionString;
 9
10con.Open();
11
12IDbTransaction transaction = con.BeginTransaction(
13   IsolationLevel.ReadUncommitted);
14insertCommand.Transaction = transaction;
15
16try {
17   for (int i = 0; i < 100; i++) {
18      helper.ExecuteCommand(insertCommand, i + 1, DateTime.Now, null);
19   }
20   transaction.Commit();
21} catch {
22   transaction.Rollback();
23} finally {
24   con.Close();
25}
26

关于DbHelper，请参看：

http://cavingdeep.cnblogs.com/category/37490.html

下载及Announcements

http://dbhelper.tigris.org