第一段略。。。

大多数讲闭包的文章都是说函数式语言，因为它们往往对闭包的支持最完善。当你在使用函数式语言时，很可能已经清楚了解了什么是闭包，所以我想写一篇在经典OO语言出现的闭包有什么用处应该也是很合适的事情。这篇文章我准备讲一下C#（1、2、3）和JAVA（7以前版本）的闭包。

什么是闭包？

简单来讲，闭包允许你将一些行为封装，将它像一个对象一样传来递去，而且它依然能够访问到原来第一次声明时的上下文。这样可以使控制结构、逻辑操作等从调用细节中分离出来。访问原来上下文的能力是闭包区别一般对象的重要特征，尽管在实现上只是多了一些编译器技巧。

利用例子来观察闭包的好处（和实现）会比较容易， 下面大部份内容我会使用一个单一的例子来进行讲解。例子会有JAVA和C#（不同版本）来说明不同的实现。所有的代码可以点这里下载。

需求场景：过滤列表

按一定条件过滤某个列表是很常见的需求。虽然写几行代码遍历一下列表，把满足条件的元素挑出来放到新列表的“内联”方式很容易满足需求，但把判断逻辑提取出来还是比较优雅的做法。唯一的难点就是如何封装“判定一个元素是否符合条件”逻辑，闭包正好可以解决这个问题。

虽然我上面说了“过滤”这个词，但它可能会有两个截然不同的意思“把元素滤出来放到列表里”或者把“把元素滤出来扔掉”。比如说“偶数过滤”是把“偶数”保留下来还是过滤掉？所以我们使用另一个术语“断言”。断言就是简单地指某样东西是不是满足某种条件。在我们的例子中即是生成一个包含了原列表满足断言条件的新列表。

在C#中，比较自然地表现一个断言就是通过delegate，事实上C# 2.0有一个Predicate<T>类型。（顺带一提，因为某些原因，LINQ更偏向于Func<T, bool>；我不知道这是为什么，相关的解释也很少。然而这两个泛型类的作用其实是一样的。）在Java中没有delegate，因此我们会使用只有一个方法的interface。当然C#中我们也可以使用interface，但会使得代码看起来很混乱，而且不能使用匿名函数和拉姆达表达式－C#中符合闭包特征的实现。下面的interface/delegate供大家参考：

// Declaration for System.Predicate<T>
public delegate bool Predicate<T>(T obj)

// Predicate.java
public interface Predicate<T>
{
    boolean match(T item);
}

在两种语言中过滤用的代码都比较简单，得先说明在这里我会避免使用C#的Extension Method来让代码看起来更加简单明了。－但是使用过LINQ的人要注意where这个Extension Method。（它们的延迟执行有些区别，但这里我会避免触及）

// In ListUtil.cs
static class ListUtil
{
    public static IList<T> Filter<T>(IList<T> source, Predicate<T> predicate)
    {
        List<T> ret = new List<T>();
        foreach (T item in source)
        {
            if (predicate(item))
            {
                ret.Add(item);
            }
        }
        return ret;
    }
}

// In ListUtil.java
public class ListUtil
{
    public static <T> List<T> filter(List<T> source, Predicate<T> predicate)
    {
        ArrayList<T> ret = new ArrayList<T>();
        for (T item : source)
        {
            if (predicate.match(item))
            {
                ret.add(item);
            }
        }
        return ret;
    }
}

（两种语言中我都写了一个Dump方法用来输出指定list的内容）

现在我们已经定义好“过滤”的方法，接下来就是要调用它。为了演示闭包的重要作用，我会先使用一个简单的不需要使用到闭包都能解决的案例，然后再进一步到比较难的案例。

过滤案例1：找出长度较短的字符串（固定长度）

我们的需求场景都会比较简单基础，但希望大家能从中看出它们的不同之处。我们将会有一个字符串list，然后根据这个list生成另一个只包含长度较“短”的字符串list。建立list很简单－建立断言才是难点。

在C# 1.0中只能通过单独的方法来表现一个断言逻辑，然后再创建一个delegate指向该方法。（当然由于代码使用了泛并不能真地在C# 1.0下面通过编译，但要注意delegate实例是如何被建立的－这是重点）

// In Example1a.cs
static void Main()
{
    Predicate<string> predicate = new Predicate<string>(MatchFourLettersOrFewer);
    IList<string> shortWords = ListUtil.Filter(SampleData.Words, predicate);
    ListUtil.Dump(shortWords);
}

static bool MatchFourLettersOrFewer(string item)
{
    return item.Length <= 4;
}

在C# 2.0中有三种方式实现，第一，使用上面一样的代码；第二，利用方法组转换（Method Group Conversion）对代码进行简化；第三，利用匿名函数将断言直接写在调用上下文中。使用方法组转换比较浪费时间－它只是把new Predicate<string>(MatchFourLettersOrFewer) 变成了 MatchFourLettersOrFewer。在示例代码中有它的实现（在Example1b.cs中）。相对而言，匿名函数要有趣得多：

static void Main()
{
    Predicate<string> predicate = delegate(string item)
        {
            return item.Length <= 4;
        };
    IList<string> shortWords = ListUtil.Filter(SampleData.Words, predicate);
    ListUtil.Dump(shortWords);
}

这样一来，就不再需要一个外部独立的方法用来封装断言逻辑，并且，断言放在了被使用的点上。很好很强大。它背后是怎么工作的呢？如果你用ildasm或者reflector去看一下生成的代码，你会发现其实它了第一个版本产生的代码很大程度是一样的，编译器只是帮我们完成了某些工作。稍后我们会看到它更强悍的能力。

在C# 3.0中除了有上面三种方式，还有拉姆达表达式。对于本文来讲，拉姆达表达式只是匿名函数的一个简化形式。（这两种东东最大的区别在于LINQ中的拉姆达表达式能被转换成表达式树，但这与本文无关）使用拉姆达表达式：

static void Main()
{
    Predicate<string> predicate = item => item.Length <= 4;
    IList<string> shortWords = ListUtil.Filter(SampleData.Words, predicate);
    ListUtil.Dump(shortWords);
}

由于在右边使用了<=，看起来像是有个大箭头指着item.Length，但为了保持前后一致，只好请大家将就着看了。这里其实可以写成等价的Predicate<string> predicate = item => item.Length < 5；

在Java中没有delegate－只能实现上面定义的interface。最简单的方法就是定义一个类并实现该interface，如：

// In FourLetterPredicate.java
public class FourLetterPredicate implements Predicate<String>
{
    public boolean match(String item)
    {
        return item.length() <= 4;
    }
}

// In Example1a.java
public static void main(String[] args)
{
    Predicate<String> predicate = new FourLetterPredicate();
    List<String> shortWords = ListUtil.filter(SampleData.WORDS, predicate);
    ListUtil.dump(shortWords);
}

这里没有使用任何华丽的语言特性，为了实现一点小小的逻辑，它使用了一整个独立的类。根据Java的惯例，类应该放在单独的文件里，这使得程序的可读性变差。当然可以使用嵌套类的方式来避免这种问题，但逻辑还是离开了使用它的地方－相当于啰嗦版的C# 1.0解决方案。（这里不打算给出嵌套版的实现代码，有需要的朋友可以看看打包代码里面Example1b.java。）Java可以通过匿名类把代码书写成内联的方式，在匿名类的光芒照射下，代码进化了：

// In Example 1c.java
public static void main(String[] args)
{
    Predicate<String> predicate = new Predicate<String>()
    {
        public boolean match(String item)
        {
            return item.length() <= 4;
        }
    };
    
    List<String> shortWords = ListUtil.filter(SampleData.WORDS, predicate);
    ListUtil.dump(shortWords);
}

如你所见，比起C# 2.0和C# 3.0的代码，这个显得还是比较啰嗦了点，但至少代码被放在了它应该在的地方。这就是Java目前支持的闭包……接下来本文进入第二个例子。

过滤案例2：找出长度较短的字符串（可变长度）

目前为止我们的断言并不需要访问到原来的“上下文”－长度是硬编码的，然后字符串是以参数的形式传进去的。现在，需求变动一下，允许用户指定多长的字符串才算是合适的。

首先，我们回到C# 1.0。它其实不支持真正的闭包－找不到一块简单的地方来存储我们需要的变量。当然，我们可以在当前方法的上下文中声明一个变量来解决这个问题（比如利用静态成员变量），但这明显不是一个好的解决方法－理由只有一个，类马上变成了线程不安全的。解决的方法就是不要把状态存储在当前上下文中，转而存储在新建的类中。这么一来，代码看起来跟原来的Java代码非常相似，区别只是这里使用delegate，而Java使用interface。

// In VariableLengthMatcher.cs
public class VariableLengthMatcher
{
    int maxLength;

    public VariableLengthMatcher(int maxLength)
    {
        this.maxLength = maxLength;
    }

    /// <summary>
    /// Method used as the action of the delegate
    /// </summary>
    public bool Match(string item)
    {
        return item.Length <= maxLength;
    }
}

// In Example2a.cs
static void Main()
{
    Console.Write("Maximum length of string to include? ");
    int maxLength = int.Parse(Console.ReadLine());

    VariableLengthMatcher matcher = new VariableLengthMatcher(maxLength);
    Predicate<string> predicate = matcher.Match;
    IList<string> shortWords = ListUtil.Filter(SampleData.Words, predicate);
    ListUtil.Dump(shortWords);
}

相对来说，C# 2.0和C# 3.0的改动要小得多：只需将硬编码的常量改成变量即可。先不管这背后的原理－一会看完Java版的代码后再来研究这个问题。

// In Example2b.cs (C# 2)
static void Main()
{
    Console.Write("Maximum length of string to include? ");
    int maxLength = int.Parse(Console.ReadLine());

    Predicate<string> predicate = delegate(string item)
    {
        return item.Length <= maxLength;
    };
    IList<string> shortWords = ListUtil.Filter(SampleData.Words, predicate);
    ListUtil.Dump(shortWords);
}

// In Example2c.cs (C# 3)
static void Main()
{
    Console.Write("Maximum length of string to include? ");
    int maxLength = int.Parse(Console.ReadLine());

    Predicate<string> predicate = item => item.Length <= maxLength;
    IList<string> shortWords = ListUtil.Filter(SampleData.Words, predicate);
    ListUtil.Dump(shortWords);
}

Java版的代码（使用了匿名类的那个版本）改动也比较简单，但有一点不爽的是－必须把参数声明为final。了解其原理前先来看一下代码：

// In Example2a.java
public static void main(String[] args) throws IOException
{
    System.out.print("Maximum length of string to include? ");
    BufferedReader console = new BufferedReader(new InputStreamReader(System.in));
    final int maxLength = Integer.parseInt(console.readLine());
    
    Predicate<String> predicate = new Predicate<String>()
    {
        public boolean match(String item)
        {
            return item.length() <= maxLength;
        }
    };
    
    List<String> shortWords = ListUtil.filter(SampleData.WORDS, predicate);
    ListUtil.dump(shortWords);
}

那么，C#和Java的代码到底有什么不同呢？在Java中，变量的值被匿名类捕获。在C#中，变量本身被delegate捕获。为了证明C#捕获了变量本身，我们来改一下C# 3.0的代码，使变量的值在变量在过滤后发生改变，看看改变是否反映到下一次过滤：

// In Example2d.cs
static void Main()
{
    Console.Write("Maximum length of string to include? ");
    int maxLength = int.Parse(Console.ReadLine());

    Predicate<string> predicate = item => item.Length <= maxLength;
    IList<string> shortWords = ListUtil.Filter(SampleData.Words, predicate);
    ListUtil.Dump(shortWords);

    Console.WriteLine("Now for words with <= 5 letters:");
    maxLength = 5;
    shortWords = ListUtil.Filter(SampleData.Words, predicate);
    ListUtil.Dump(shortWords);
}

注意，我们只是改变局部变量的值，而并没有重新创建delegate的实例，或者其它等价的操作。由于delegate其实是直接访问这个局部变量，所以其实它是能够知道变量发生的变化。再进一步，接下来在断言逻辑中直接对变量进行修改：

// In Example2e.cs
static void Main()
{
    int maxLength = 0;

    Predicate<string> predicate = item => { maxLength++; return item.Length <= maxLength; };
    IList<string> shortWords = ListUtil.Filter(SampleData.Words, predicate);
    ListUtil.Dump(shortWords);
}

我不打算再深入地讲这些是怎么实现的－《C# in Depth》第5章讲的都是这些细节。只是希望你们一些对“局部变量”的观念认识被完全颠倒。

我们已经看到了C#是如何对捕获的变量进行修改的，那Java呢？答案只有一个：你不能对捕获的变量进行修改。它已经被声明为final，所以这个问题其实是很无厘头的。而且就算你人品值爆糟，突然间能对该变量进行更改，也会发现断言逻辑根本对修改毫无反应。变量的值在断言声明的时候被拷贝并存储到匿名类内。不过，对于引用变量，它的成员发生改变还是能够被知道的。比如说，如果你引用了一个StringBuilder，然后对它进行Append操作，那在匿名类中是可以看到StringBuilder的改变。

对比捕获策略：复杂性VS功能

明显Java的设计局限性比较大，但也同时也比较容易理解，不容易发生概念混淆的情况，局部变量的行为和一般情况下没什么不同，大多数情况下，代码看起来也更简单易懂。比如下面的代码，利用Java runable interface和.NET Action delegate－两个都是会执行一些操作，不需要参数，也不返回任何值。首先看看C#的代码：

// In Example3a.cs
static void Main()
{
    // First build a list of actions
    List<Action> actions = new List<Action>();
    for (int counter = 0; counter < 10; counter++)
    {
        actions.Add(() => Console.WriteLine(counter));
    }

    // Then execute them
    foreach (Action action in actions)
    {
        action();
    }
}

会输出些什么？其实我们只声明了一个counter变量－所以其实所有的Action捕获的都是同一个counter变量。结果就是每一行都输出数字10。为了把代码“修正”到我们预期的效果（如输出0到9），则需要在循环体中使用另一个局部变量：

// In Example3b.cs
static void Main()
{
    // First build a list of actions
    List<Action> actions = new List<Action>();
    for (int counter = 0; counter < 10; counter++)
    {
        int copy = counter;
        actions.Add(() => Console.WriteLine(copy));
    }

    // Then execute them
    foreach (Action action in actions)
    {
        action();
    }
}

这样，每次循环体在执行的时候，都会取得一份counter的拷贝，而不是它本身－所以每个Action取得了不同的变量值。如果看一下编译器生成的代码，你就会完全明白这种结果是合情合理的，但这对于大多数第一次看到代码的程序员来说，其直觉得出的结果往往是相反的。（包括我）

在Java中则完全不存在第一个例子的情形－你根本不可能捕获到counter变量，因为它并没有被声明为final。使用final变量，最终得到下面类似C#的代码：

public static void main(String[] args)
{
    // First build a list of actions
    List<Runnable> actions = new ArrayList<Runnable>();        
    for (int counter=0; counter < 10; counter++)
    {
        final int copy = counter;
        actions.add(new Runnable()
        {
            public void run()
            {
                System.out.println(copy);
            }
        });
    }
    
    // Then execute them
    for (Runnable action : actions)
    {
        action.run();
    }
}

我到底想讲些什么？

在例子中，我们可以看到了闭包好处其实不多。当然，我们把控制结构和断言逻辑成功分拆开来，但这并没有使代码比原来的更加简洁。这种事经常发生，新特性在简单的情形往往是看起来没想像中那么好，有那么大的作用。闭包通常带来的好处，是可组合性，如果你觉得这么说有些扯淡，没错－这也是问题的一部份。当你对闭包运用很熟练甚至有些迷恋的时候，两者之间的联系就会变得越来越明显，否则是不容易看出其玄妙所在。

闭包不是被设计来提供可组合性。它做的不过是让delegate实现起来更加简单（或者只有一个方法的interface，下面统一用delegate简称）。如果没有闭包，直接写一个循环结构其实是比把封装了一些相关逻辑的delegate传给另一个方法去执行循环要来得简单。即使可以通过delegate调用“在已有类中添加的方法”，最终你还是没办法把逻辑代码放在最合适的地方，而且没了闭包提供的信息存储便利，则必须依靠方法外部的上下文来存储某些信息。

可见，闭包使delegate更加易用。这就意味着值得将API设计成为使用delegate的形式。（我认为这种情况并不适用于.NET 1.1下面基本上只能用来处理线程和订阅事件的delegate）当你开始用delegate的方式去解决问题时，如何去做变得显而易见。比如，最常见的就是创建一个用AND或者OR（也包括其它逻辑操作符）将两个断言串连起来的Predicate<T>。

当把某个delegate产生的结果装填进另一个列表，或者对delegate进行加工产生新的，就会有完全不同的组合方式，如果将逻辑当作可以被传递的某种数据来考虑时，所有不同类型的选择都是可行的。

这种编码方式的好处远不止上面说的那么多－整个LINQ都是基于这种方式。我们创建的过滤器只是一个可以将有序数据转换成另一组数据的例子。另外还有排序，分组，联接另一组数据和Projecting等操作。使用传统的编码方式去写这些操作虽不是非常痛苦的事情，但是如果“数据管道”中转换操作越来越多时，复杂性随之提高，另外，LINQ赋于对象延迟执行和数据流的能力，这种一次循环执行多次操作方式明显比多次循环执行一次操作要节约很多内存。即使每一个单独的转换操作被设计得很聪明高效，复杂性上还是依旧无法取得平衡－通过闭包封装简明扼要的代码片断以及良好设计的API带来的组合能力可以很好去除复杂性。

结论

刚开始接触闭包，可能不会对它有深刻印象。当然，它使得你的interface或者delegate实现起来更简单（取决于语言）。其威力只有在相关类库利用了它的特性之后才能体现出来，允许你将自定义行为放在合适的地方。当同一个类库同时允许你将几个简单的步骤以比较自然的方式组合起来实现一些重要行为时，其复杂性也只是几个步骤的总和－而不是大于这个总和。我不是赞同某些人鼓吹的可组合性是解决复杂性的银弹，但它肯定是很有用的技巧，而且由于闭包使得它在很多地方可以得以实施。

拉姆达表达式最重要特点就是简洁。看一下之前的Java和C#的代码，Java的代码显然比较笨拙冗长。很多Java闭包的倡议都是想解决这个问题。稍后我会发一篇文章讲一下我对这些不同倡议的看法。

　　固然，顾全当前现实情况是必要，可是世界并不是一成不变的，尤其是风云变幻的商业市场，用户会变化。从Google以及其它很多Web 2.0的网站上可以看出来，虽然表面上，它们的出现改变了很多用户的使用习惯，上网习惯；其实是人们本来就有了那种需要，那种倾向，而Google及那些成功的网站注意到了这些潜在的需要，然后以用户为依归，创造出适合用户需要的产品，因而获得成功。也就是说，如果一个网站，一个创意，根本就不符合人们需求的时候，它根本就不可能发展壮大。

　　不是我扯远了，而是有些人忽略了一个本来应该有的共识：用户是上帝，是用户选择产品，产品最多只能针对某个群体。

　　用户是自由的，他们可以选择使用IE，可以选择Firefox，可以选择Safari，可以选择Opera，等等，正所谓萝卜青菜，各有所爱。你BS某个群体用户，别人一样也会BS你，就更不可能有5%的用户去浏览你的网站。若是想做一个成功的Web应用,剥夺用户的选择权是不明智的，看一下那些成功的网站，有哪一个不是往“标准”靠拢的？有哪一个不是跨浏览器的？

　　对用户们来讲，他们根本就不关心一个网站开发的技术难度。他们关心的是适不适合他们用，好不好用，在他们使用惯用的浏览器浏览使用网站的时候，出现了页面混乱，无法运行，影响用户体验的情况，他们就会觉得这个网站根本就靠不住。就别说指望留住这些用户，甚至于当他们和朋友谈起这个网站的时候，也会嗤之以鼻。有时候，用户可能会委曲求全使用某种他们不喜欢的浏览器，但有更好的网站出现时，他们会毫不犹豫地飞奔过去。

　　对客户们或者老板来讲，目前实施标准化带来的跨浏览器问题只会让他们支付更多的成本。这些额外的成本其实并不会带来额外的好处，额外的利润，而仅仅是避免本来不应该存在的负面效应。所以未来的浏览器一定会向“标准”靠拢。

　　特别是微软自己也在向“标准”靠拢的时候，仇恨标准是没有道理的，仇恨那些对标准支持比较好的浏览器更加没有道理。仇恨这些就是在仇恨自己的生命，仇恨自己的自由，仇恨自己的客户。过往IE也好，Netscape也好，即使那么的辉煌也已是当年之勇，历史是向前推进的，IE6能撑六年之久还不是因为没有竞争者的存在？一个商业公司，当客户只有他一个选择的时候，还指望这个公司能自己推陈出新，发展迅速是不现实的事情。有竞争者存在的行业才会发展，但中间一定会有一些比较强势，所以需要一些立场比较中立代表用户（包括开发者）利益的第三者来制定规则让这些公司公平竞争，让“标准”去靠拢微软，就像让裁判偏袒某一球队一样可笑。

　　现下由于“标准”普及度不够而产生的“跨浏览器”是高成本，低回报的，势必式微，绝非长久之计，与其希冀靠此为生，倒不如把希望寄于“标准”普及，把更多的精力投入到开发更好的Web应用上面。普通用户也就罢了，但如果身为Web开发者还在唯IE是瞻，则是令人扼腕。

(基于快捷方式的Multiple IE)

所幸江山代有才人出，日前从朋友处听来有一名为IETester的Freeware也有相似的功能，支持IE8 beta 1, IE7 IE 6 and IE5.5 以及 Vista 和 XP 操作系统。

(基于Tab模式的IETester)

IETester当前版本是0.2，安装包是23.7M，XP下安装需要先装IE7，运行的界面如上，没有Multiple IE弹出OK窗口的问题。按照作者所说，目前已知的问题有：

• 当窗口大小改变的时候，页面内容可能会消失（作者改进中）。
• 上一页/下一页功能不正常。
• Focus功能不正常。

使用中遇到有其它bug可以到这里反馈。

　　当完成一件事能用更简单基于只能用更简单的方式去做的时候，应该是一件自然而然的事才对。

　　可是，当ViewState被切下来的时候，我就很惊奇了，失去了ViewState的WebForm，Postback自然也没什么意义了，那么，原本隐藏在WebForm后面的HTTP机制不是又暴露在用户面前？那么，还能像WinForm那样轻松地定阅处理各种事件吗？那么，WebForm所倡导的RAD理念呢？(千万别ignore理念这个词)

　　接下来甚至于内联的写法也被提出来了，怎么说呢，既然是内联写法了，那HTML的细节也暴露无遗了吧？那如此这般的WebForm相对于MVC又有什么优点了？组件化没了，RAD没了，可视化也没了，那究竟什么是WebForm？难道说一个aspx + aspx.cs就可以说它是WebForm了？那这WebForm的定义也太宽太广了吧！真是相当地期待 ScottGu 站出来说一究竟什么是WebForm以平息这种乱局。

　　被阉割了的WebForm相比之MVC究竟还有什么优势？对Web开发新手而言，门槛似乎比MVC高了吧？不仅仅是需要了解HTML、HTTP等这些相对低层的东西，就是WebForm开发方面根本就不会有太多阉割版WebForm的资料可以参考。若是对页面代码的控制粒度有那么高的话，何不放开怀抱去拥抱质的变化？我想MVC的倡导者原先也极有可能是阉割的WebForm，到了一定程度，阉割版的WebForm也满足不了需求的时候，质的变化就出现了，就是不肯拥抱变化的态度，才让我们总是跟在人家后面跑！

　　WebForm比之MVC即有如男人之比女人，男人做事粗放但办事效率高，女人做事细致而繁琐。硬是要他们同质化最终只会不伦不类。唉，难道潮流就是流行这些中性的东西，像什么超女超男的……

　　有PHP背景的界面人员也太不具代表性了，要是和广大开发人员合作的界面人员都有PHP背景，那世界就和谐了，那我们就是社会主义最终形态了！而且我就假装地球上的界面人员都有PHP背景了吧，用MVC的话你连什么组件都不用跟他讲了，直接告诉他我给你什么数据，你给我POST什么数据不就OK了？

　　看了也许您会觉得我在说WebForm不如MVC似的，所以我要强调一下：不是男人比不上女人，只是不要让男人去干女人干的事！

　　Separation of Concerns　－　关注点分离，说到这一点，我感觉国内.NET社区还是少一种开放的态度，昨天看《自由》兄的一篇贴子，评论里有位同志提了一句“MVC/IoC/ORM的理念相似”，后面竟然有人回说“不知道mvc和ioc/orm的相似性在哪里...”然后还讲了很多，很无奈啊！理念这个词完全被ignored，我想请大家一定要互相尊重，认真地阅读他人的文字。

记者：“脚本语言仍然会大行其道”，在这种情况下，您认为Java和脚本语言各在哪些领域发挥哪些作用呢？

纯月：随着Java应用的深入，人们渐渐开始不再把Java作为万金油。Java在Web开发上的确不具有明显的优势，Struts，JSF等框架相比基于脚本的语言增加了开发复杂性，很多开发者开始回到基于JSP的简单MVC2+持久层的方案。甚至在其他表现层上，例如桌面应用中Java都不具有优势。而Java和JEE更适合开发企业后端系统，例如消息中间件，ESB等。

mvc模式：
view接收用户输入，把命令传到controller
controller处理命令，更新model
model被更新后，会通知view需要update
view更新后向用户显示
mvc2模式：
由于mvc1中，model可以通知view，然后view就可以被更新，这在windows程序中很常见，像MFC的frame-document-view架构，如果document改变了，他会主动通知view进行update
但是在web中，作为model的java bean更新后，无法调用作为view的jsp（而且view通常很多，需要选一个），因此改为mvc2模式：
view接收用户输入，把命令传到controller
controller处理命令，更新model
model被更新后，controller会选一个view并forward到这个jsp，附带把model放到request参数
这个view获得model然后显示

　　言简意骇，或者可以把这些概念引用到.NET里来，把MonoRail的实现称之为MVC2，这样就不会在概念上和传统的MVC有所冲突了吧。

　　但若要使用MonoRail，事情就麻烦了，初级阶段需要了解的东西会比WebForm多出很多来，比如说，首先得习惯用传统的HTTP视角去看待客户端和服务器之间的交互，像是在做Classical ASP/PHP做开发一样，每一次的交互都是独立的。你要了解什么是HTML，什么是FORM，什么是INPUT，为了实现一些比较特别的功能，还需要Javascript，然后还要另外还要学习模板语法……

　　不难得出的结义是，WebForm比MonoRail容易上手。特别是对没做过web开发的人来讲，它隐藏了web的许多底层的东西，展现出来是一个近似WinForm的快速开发方式。行文至此，可以说，WebForm比MonoRail更像是一把瑞士军刀，难道WebForm的功能不是比MonoRail更加强大吗？你要什么控件就给你什么，不需要另外去弄，都集成好了，不是吗？反过来看MonoRail，原本在WebForm上简单一拖就有的控件，却需要另外花力气去实现。

　　瑞士军刀是好东西，功能强大，携带方便，当然也没有什么学习成本，但是，这些优点不是MonoRail所具备的。

　　随着一步一步将WebForm应用到开发中去，我意识到，WebForm也只是易上手而已，当要对控件进行定制时，就不得不深入去了解控件的模型，事件，方法等，有时候已有的控件也未必能满足定制的需求，又不得不依赖于第三方控件，找不到第三方控件时，则得自己进行控件开发，当涉入到控件开发领域时（主要指自定义控件），我才了解到什么叫做高昂的学习成本。前前后后我曾经花了三个月在这上面，大概也是能做到一般复杂的控件开发而已。更加不幸的是这么一来，本来由设计师做的界面修改工作变成了要我来做。唉，罪过啊罪过，这简直是在浪费生命。

　　我想，既然大家选择了做Web开发，那怎么可能不去了解什么是HTTP？什么是HTML？什么是Javascript？WebForm能帮你挡得了一时，可 能帮你挡一世？要知道，即使你将来换了开发平台，掌握这些基础知识即使不是不可或缺的，至少也是大有裨益的。

　　然而，对于一个基础扎实的Web开发人员来讲，MonoRail还剩多少东西可学？看完MonoRail的 Getting Statrted Sample 就可以开工了，把它的Documentation全部看完也花不了多少时间。但若是要把WebForm玩转，进入控件开发领域的时候，不但要了解HTTP/HTML/Javascript/...等等这些底层的东西，还得额外去了解WebForm的生命周期，控件继承树，各种各样的接口……

　　首先是我写的一段用来模拟私有成员的代码:

function Foobar(parameter) {
	var privateVariable = "I'm private Variable";
	var privateFunction = function() {
		return "I'm privateFunction and privateVariable is : " + privateVariable;
	}

	this.publicVariable = "I'm public Variable";
	this.publicFunction = function() {
		document.write("parameter : " + parameter + "<br />");
		document.write("privateVariable : " + privateVariable + "<br />");
		document.write("privateFunction : " + privateFunction() + "<br />");
		document.write("publicVariable : " + this.publicVariable + "<br />");
	}
}
var foobar = new Foobar("I'm paramter");
foobar.publicFunction();
document.write("typeof(foobar.privateVariable) : " + typeof(foobar.privateVariable) + "<br />");
document.write("typeof(foobar.privateFunction) : " + typeof(foobar.privateFunction) + "<br />");
document.write("typeof(foobar.publicVariable) : " + typeof(foobar.publicVariable) + "<br />");
document.write("typeof(foobar.publicFunction) : " + typeof(foobar.publicFunction) + "<br />");

　　输出内容：

parameter : I'm paramter
privateVariable : I'm private Variable
privateFunction : I'm privateFunction and privateVariable is : I'm private Variable
publicVariable : I'm public Variable
typeof(foobar.privateVariable) : undefined
typeof(foobar.privateFunction) : undefined
typeof(foobar.publicVariable) : string
typeof(foobar.publicFunction) : function

　　可以看到，privateVariable和privateFunction都被成员的隐藏了起来。再看一段来自dojo类库的代码：

var getImgInPositionedDivHtml = (function(){
    var buffAr = [
        '<div id="',
        '',   //index 1, DIV ID attribute
        '" style="position:absolute;top:',
        '',   //index 3, DIV top position
        'px;left:',
        '',   //index 5, DIV left position
        'px;width:',
        '',   //index 7, DIV width
        'px;height:',
        '',   //index 9, DIV height
        'px;overflow:hidden;\"><img src=\"',
        '',   //index 11, IMG URL
        '\" width=\"',
        '',   //index 13, IMG width
        '\" height=\"',
        '',   //index 15, IMG height
        '\" alt=\"',
        '',   //index 17, IMG alt text
        '\"><\/div>'
    ];
    return (function(url, id, width, height, top, left, altText){
        buffAr[1] = id;
        buffAr[3] = top;
        buffAr[5] = left;
        buffAr[13] = (buffAr[7] = width);
        buffAr[15] = (buffAr[9] = height);
        buffAr[11] = url;
        buffAr[17] = altText;
        return buffAr.join('');
    }); //:End of inner function expression.
})();

　　这是来自于dojo类库的一段代码，基本上，getImgInPositionedDivHtml是一个用来创建绝对定位div的html代码。这个div是有固定的模式的，变动的只是具体的一些属性，所以它用了一个buffAr来承载这个模式，getImgInPositionedDivHtml在接收到具体的属性值(url, id, width, height, top, left, altText)，就会把它放到buffAr的相应位置，再返回buffAr的join后的字符串。而无论getImgInPositionedDivHtml被执行多少次，buffAr只会被创建一次，类似于静态成员的行为。当然，在真正的面向对向语言中，我们是不能这么做的，因为还要考虑到线程安全的问题，有点扯远了。

　　这两段代码，都是利用了Javascript特有的闭包来实现各自的效果，什么是闭包呢？

　　我们知道，变量有作用域的概念，在一个函数体中，使用var声明局部变量只在函数体中能被引用，而在函数外部则是无法访问该变量的。理论上，局部变量会在函数执行完毕之后被释放，除非它有在其它地方被引用（也很有可能是在脚本被卸载的时候才统一回收的，但这不影响它能否被引用），最容易理解的就是被return回上层调用：

function getLocalVar() {
	var localVar = "I'm local var";
	return localVar;
}
var globalVar = getLocalVar();

　　作用域的概念在很多编程语言中都有存在，在Javascript中一样也有，特别的地方就在于Javascript是一种动态语言，它可以定义内嵌函数。当你在一个函数内部定义一个新的函数时，内嵌函数就可以引用该函数的局部变量。：

function OutterFunction() {
	var outterVar;
	function InnerFunction() {
		return outterVar;
	}
}

　　当OutterFunction每次被调用时，解释器会为它分配一个栈区，所有的局部变量都会被放到这个栈区（闭包开始），栈区内的局部变量都是相互可见的，而InnerFunction也是局部变量之一，所以当OutterFunction执行完毕退出以后，InnerFunction依然可以访问到其他的局部变量（闭包形包）。要注意的是InnerFunction每次都被重新创建，每次返回都是不同的。换句话说，闭包就是指返回出来的InnerFunction可以访问到OutterFunction的局部变量这种情形。

　　理解并合理地使用闭包可以使程序更加灵活和优雅。很多Javascript类库都有闭包的应用，所以，如果需要经常和Javascript打交道的话，闭包是无法绕过的概念。

　　WebForm的开发理念源自于WinForm，基于控件的拖放及后台代码编写的开发方式的而且确是很方便快捷的开发方法，WinForm的成功很好地说明了这一点。整个WebForm的核心就是控件，以封装手，重用为目的而存在的控件使得WebForm极为容易上手。得力于WebForm方便快捷的开发方式，.NET在企业开发领域取得了巨大成功。

　　HTTP协议是无状态，WebForm为了要像WinForm那样保持控件的状态，不得不依赖于ViewState/Postback这些机制。总的来说，WebForm是以控件为核心，依赖于ViewState、Postback机制最终构成的。脱离了它们，WebForm则不能称之为WebForm。

　　然而，控件在带来方便的同时，其生成的HTML代码也难以维护；ViewState带来状态维护的方便，同时也造成了性能的损耗；在Postback机制中有一点让我很困惑的是：很多时候我们要在Page_Load判断是否第一次请求然后执行一些初始化（如绑定的动作）。为何Microsoft不在Page上加多一个Initialize之类的事件来代替现有的在Page_Load中判断IsPostback。这样做一来会比较优雅，二来也更加像WinForm了。

　　再来看看aspx和cs，它们是WebForm表现和代码分离的形式，是的，仅仅只是表现和代码的分离而已。aspx上面的控件依赖于后台cs的控制，而后台的cs则依赖于aspx的存在。分离是物理上的，逻辑上它们还是紧密地结合在一起的，没有了谁都不行。专业点来说，它们是耦合在一起的。

　　在企业开发领域，由于软件将会在企业内部有限范围内使用，通常则不会对界面有太高要求，甚至大多数时候都是开发人员直接拼出来的界面。因此，WebForm生成的代码再恶心，再难以维护，aspx/cs耦合再严重也没什么影响。ViewState/Posback带来的性能损耗在使用人数有限的企业应用中也并不突出。所以用WebForm来代替一部份企业CS（Client/Server）应用好处是很明显的，比如说，系统更新时只需更新服务器，而不用每次分发客户端。

　　可是，毕竟不是所有使用.NET的人都在做企业开发，当用WebForm来做网站开发，我感觉就像牛刀杀鸡一般。在网站开发的世界里，我们的客人，通常会对界面会有所要求，甚至于有时候会要求生成的HTML代码要符合W3C标准……所以，对HTML代码的控制变得重要起来；另一方面，作为放在internet上供众人浏览的网站，ViewState/Posback带来的性能开销变得不容忽视起来；aspx/cs耦合使得无法将它们作为设计师和程序员职责分离的承载体（特别是当程序员在页面上扔一些SqlDataSource之类的控件）。

　　牛刀不是不能杀鸡，但很多人毕竟不习惯用牛刀来杀鸡。MVP(Model-View-Presenter)才是真正切合网站开发实际情况的开发方式。虽然WebForm比MonoRail要强大，很多，但它毕竟不适合我们做网站开发的。

　　MonoRail就是适合网站开发的一套MVP开发框架。与WebForm的开发理念不同，它着重于职责的分离。当Controller(MonoRail中的Presenter称为Controller)和View被切割隔离开来时，设计师和程序员和谐地分工合作也成为了可能（世事无绝对）。MVP的理念中，没有控件，没有Posback，当然也没有ViewState，客户端和服务器间的交流回归到了原始的Form/QueryString/Cookie的方式（难道这样不是更自然吗？），借由此，设计师重新找回了对HTML代码的控制权。程序员在Controller里专注于数据的处理，设计师（我通常认为设计师应该具有一定的html知识）通过学习简单的模板控制代码后，模板文件则会成为他的势力范围。

　　Contoller和View之间会通过松散的PropertyBag进行沟通，而不像WebForm的asp/cs那样紧密（cs会对aspx上的控件在在引用，或aspx上的控件会绑定cs产生的数据）。因此，View对呈现的逻辑有绝对的控制权，而单纯的View上的修改调整也不会对Controller产生影响。即使设计师把View全删光了，程序也不会出错，那么，你就再也不必为设计师的过失而背黑锅了。而本来应该由设计师完成的修改也不需要程序员来做了。

　　无论是WebForm也好，MonoRail也好，最大的区别还是它们的理念。其实，只要你有好的意识，使用WebForm一样也可以把界面和控制分离得很好；相反，在MonoRail的Controller里一样可以生成HTML代码再传给View……

追加两个分别用WebForm和MonoRail实现购物车功能的Demo

Shopping Cart (WebForm)

Shopping Cart (MonoRail)