dbcc freeProcCache

在点击某个按钮,执行完后,再执行下面语句,就可以知道系统运行什么Sql和多少次了,其主要慢语句是那些了;

namespace Demo

{

public interface IFoo

    {

void Foo();

}



public class Base : IFoo

    {

public void Foo()

{

Console.WriteLine("In base's Foo function");

}

}





class Program

    {

static void Main(string[] args)

{

IFoo i = new Base();

i.Foo();

}

}

}

  在Essential .NET中，Don Box向读者简单描述了基于接口的多态调用，在堆中有一个全局接口映射表，当某个类实现了一个接口，就会在这个接口表中增加项，而增加的这些项又指向这个 具体类的Method Table中的Method，可能说的不是太清楚，就用个图来表示：

 当进行方法调用的时候，首先通过对象找到该类型的Method Table，根据偏移量找到指向Interface Offset Table的指针来定位这个Interface Offset Table，然后CLR查找调用方法在这个Offset Table的偏移量，最后调用该方法。调用的汇编代码如下：

 mov ecx, esi  -- 保存对象地址到ecx中

 mov eax, dword ptr [ecx] -- 把类型的Method Table的地址保存在eax中

 mov eax, dword ptr [eax+0ch] -- 把Interface Offset Table的地址保存在eax中

 mov eax, dword ptr [eax + interface offset] -- 根据Interface在Table中的偏移量，找到其地址并保存到eax中

 call dword ptr [eax +  method offset] -- 根据该方法的偏移量定位改方法进行调用

可以说这样的调用逻辑是很清楚容易让人理解的。

但是当我用windbg进行跟踪的时候却发现接口方法调用机制和上面所说的不同，并没有一个查找Interface Offset Table的过程，在Main函数里是这样的调用：

 mov ecx, esi --  保存对象地址到ecx中

 call dword ptr ds:[980010h]  在数据段980010h上保存的是一个指针，实际上调用的是：

 jmp mscorwks!ResolveWorkerAsmStub

 可以看到跳转到ResolveWorkerAsmStub函数里去了。而这个函数是做什么的呢，下面的代码是从SSCLI里面找到的（有兴趣的可以看看virtualcallstubcpu.hpp）：

__declspec (naked) void ResolveWorkerAsmStub()

{

// 首先保存寄存器状态

call VirtualCallStubManager::ResolveWorkerStatic //调用ResolveWorkerStatic方法

//还原寄存器状态

jmp eax //eax保存着实际上要调用的方法的地址，所以这里就开始了方法调用

}

所以猜想到在VirtualCallStubManager::ResolveWorkerStatic函数里面正确找到了方法的地址，保存在eax里。

看来到底是怎样取到该方法地址这个问题只能等下次有时间再用windbg跟踪。如果有人了解，也希望能解释一下来帮助我解答疑惑。

•   父类定义的非虚方法是否在子类中有拷贝？
•   虚方法是如何实现多态的？
•   子类继承父类的虚方法实现是否和继承非虚方法机制相同？
•   如果子类隐藏了父类的虚方法，这又是怎样实现的？

  当然问题不止这么多，关于接口方面还有很多很多疑惑，不过时间有限，一下也没办法全部弄清楚，有时间慢慢研究。我主要使用Windbg工具来跟踪调试，关于这个工具如何使用，Google一下就会有很多了。

  这些都是我自己研究加上参考资料所得，如果有不对的地方，希望大家讨论指出。

  首先看下面这段代码：

 public class Base

 {

public virtual void VirtualFun1()

{

Console.WriteLine("Base.VirtualFun1");

}

public void NoneVirtualFun1()

{

System.Console.WriteLine("Base.NoneVirtualFun1");

}

public virtual void VirtualFun2()

{

System.Console.WriteLine("Base.VirtualFun2");

}

public virtual void VirtualFun3()

{

System.Console.WriteLine("Base.VirtualFun3");

}

}



public class Derived : Base

 {

public override void VirtualFun1()

{

Console.WriteLine("Derived.VirtualFun1");

}

public new virtual void VirtualFun2()

{

System.Console.WriteLine("Derived.VirtualFun2");

}

public virtual void VirtualFun4()

{

System.Console.WriteLine("Derived.VirtualFun4");

}

}

Base类是基类，它包含三个虚方法VirtualFun1, VirtuaFun2, VirtualFun3和一个非虚方法NoneVirtualFun1。

Derived继承Base类，它重写了VirtualFun1虚方法，隐藏了Base类的VirtualFun2虚方法，然后又增加了VirtualFun4虚方法。

看看一个Base类的实例在内存中是怎样排布的：

  Object Ref表示某Base实例的引用，它指向在GC Heap中分配的Base对象，这个对象可以分为三部分：同步块索引、类型指针和字段。主要来关注类型指针，它指向该类型的Method Table，这其实是在Load Heap中分配的Type类型对象，所有该类型的实例的类型指针都指向同一个Method Table（这里表示所有Base对象的类型指针都指向同一个Method Table）。

  Method Table里面包含很多信息，这里关注有关Method这一区域，（如果想了解更详细的method table，请参考上面的文章）。

  根据在Method Table里的信息，可以知道它包含9个Method（其实应该有个字段标示有多少个虚方法，这里就没画了）。接下来就是这些method，它分为两部 分，前面一部分是所有的虚方法，后面的是非虚方法。因为所有的类型都是继承自System.Object类，所以前四个方法是Object类的虚方法 （ToString, Equals, GetHashCode, Finalize），接着是Base类定义的三个虚方法（VirtualFun1, VirtualFun2, VirtualFun3），最后是Base类的非虚方法NoneVirtualFun1以及默认的构造函数。下面再来看看Derived类型的 Method Table：

仔细对比一下这两个Method Table，可以发现这样几个特点：

• Base类中的所有虚方法在Derived类的Method Table中一一对应
• Base类中的所有非虚方法在Derived类中的Method Table并没有拷贝（这一点回答了上面的第一个问题）
• Derived类新增的虚方法都添加到继承自Base类的虚方法的后面
• 如果Derived类override Base类的虚方法，它就将该方法指向自身的实现
• 如果Derived类使用new关键字隐藏了Base类虚方法的实现，它就相当于增加了一个虚方法，而不是覆盖。

下面看看调用虚方法时如何实现多态，比如有这样一段代码

  Base b = new Derived();

  b.VirtualFun1();

编译后在我的机器上会生成这样的汇编代码：

  mov ecx, esi

  mov eax, dword ptr[ecx]

  call dword ptr [eax + 3ch]

  现在来解释这几句代码：mov ecx, esi 是将新构造的对象的地址保存在ecx寄存器中； mov eax, dword ptr[ecx] 表示ecx的值是一个指针（根据上面的图可以知道对象的头4个字节保存的是method table的地址），它将method table的地址保存到eax寄存器中，最后call dword ptr[eax + 3ch]。3ch表示偏移量，它表示该方法相对于该method table的偏址，是在该类型加载到load heap以后确定的。这样，由method table的地址加上method相对与method table的偏移量，就可以唯一确定一个方法。

  这样在调用b.VirtualFun1(); 时，由于b是Derived类的实例，所以根据它指向的托管对象找到的method table是Derived类型的method table，就能正确调用该方法。因为Derived类中override了VirtualFun1这个虚方法，所以调用的是Derived类的实现，而 如果没有override基类的虚方法，它就指向基类的该方法的实现。

  由此可以看出，CLR实现虚方法的机制主要是通过类型的method table加上该虚方法相对于method table的偏移量来确定调用具体方法的。一个虚方法在整个继承体系所有类型对应的method table中的偏移量是固定的，比如VirtualFunc1在Base类型的method table中的偏移量是3ch，它在Derived类型的method table中的偏移量也是3ch，如果还有继承自Derived类的类，也是同样，利用这种机制就实现了多态。

  结论

•   每个类型对应一个Method Table
•   子类的Method Table中包含父类的所有虚方法，而不包含父类的非虚方法
•   CLR根据对象找到它对应类型的method table，然后根据该虚方法在method table中的偏移量实现多态调用。

1. 引言

关于继承，你是否驾熟就轻，关于继承，你是否了如指掌。

本文不讨论继承的基本概念，我们回归本质，从编译器运行的角度来揭示.NET继承中的运行本源，来发现子类对象是如何实现了对父类成员与方法的继承，以最为简陋的示例来揭示继承的实质，阐述继承机制是如何被执行的，这对于更好的理解继承，是必要且必然的。

2. 分析

下面首先以一个简单的动物继承体系为例，来进行说明：

public abstract class Animal
{
    public abstract void ShowType();

    public void Eat()
    {
        Console.WriteLine("Animal always eat.");
    }
}

public class Bird: Animal
{
    private string type = "Bird";
    public override void ShowType()
    {
        Console.WriteLine("Type is {0}", type);
    }

    private string color;
    public string Color
    {
        get { return color; }
        set { color = value; }
    }
}

public class Chicken : Bird
{
    private string type = "Chicken";
    public override void ShowType()
    {
        Console.WriteLine("Type is {0}", type);
    }

    public void ShowColor()
    {
        Console.WriteLine("Color is {0}", Color);
    }
}

然后，在测试类中创建各个类对象，由于Animal为抽象类，我们只创建Bird对象和Chicken对象。

public class TestInheritance
{
    public static void Main()
    {
        Bird bird = new Bird();
        Chicken chicken = new Chicken();
    }
}

下面我们从编译角度对这一简单的继承示例进行深入分析，从而了解.NET内部是如何实现我们强调的继承机制。

（1）我们简要的分析一下对象的创建过程：

Bird bird创建的是一个Bird类型的引用，而new Bird()完成的是创建Bird对象，分配内存空间和初始化操作，然后将这个对象赋给bird引用，也就是建立bird引用与Bird对象的关联。

（2）我们从继承的角度来分析在编译器编译期是如何执行对象的创建过程，因为继承的本质就体现于对象的创建过程。

在此我们以Chicken对象的创建为例，首先是字段，对象一经创建，会首先找到其父类Bird，并为其字段分配存储空间，而Bird也会 继续找到其父类Animal，为其分配存储空间，依次类推直到递归结束，也就是完成System.Object内存分配为止。我们可以在编译器中单步执行 的方法来大致了解其分配的过程和顺序，因此，对象的创建过程是按照顺序完成了对整个父类及其本身字段的内存创建，并且字段的存储顺序是由上到下排列， object类的字段排在最前面，其原因是如果父类和子类出现了同名字段，则在子类对象创建时，编译器会自动认为这是两个不同的字段而加以区别。

然后，是方法表的创建，必须明确的一点是方法表的创建是类第一次加载到CLR时完成的，在对象创建时只是将其附加成员TypeHandle指向方法列表在Loader Heap上的地址，将对象与其动态方法列表相关联起来，因此方法表是先于对象而存在的。类似于字段的创建过程，方法表的创建也是父类在先子类在后，原因是显而易见的，类Chicken生成方法列表时，首先将Bird的所有方法拷贝一份，然后和Chicken本身的方法列表做以对比，如果有覆写的虚方法则以子类方法覆盖同名的父类方法，同时添加子类的新方法，从而创建完成Chicken的方法列表。这种创建过程也是逐层递归到Object类，并且方法列表中也是按照顺序排列的，父类在前子类在后，其原因和字段大同小异，留待读者自己体味。

结合我们的分析过程，现在将对象创建的过程以简单的图例来揭示其在内存中的分配情形，如下：

从我们的分析，和上面的对象创建过程可见，对继承的本质我们有了更明确的认识，对于以下的问题就有了清晰明白的答案：

• 继承是可传递的，子类是对父类的扩展，必须继承父类方法，同时可以添加新方法。
• 子类可以调用父类方法和字段，而父类不能调用子类方法和字段。
• 虚方法如何实现覆写操作，使得父类指针可以指向子类对象成员。
• new关键字在虚方法继承中的阻断作用。

你是否已经找到了理解继承、理解动态编译的不二法门。

3. 思考

通过上面的讲述与分析，我们基本上对.NET在编译期的实现原理有了大致的了解，但是还有以下的问题，一定会引起一定的疑惑，那就是：

    Bird bird2 = new Chicken();

这种情况下，bird2.ShowType应该返回什么值呢？而bird2.type有该是什么值呢？有两个原则，是.NET专门用于解决这一问题的：

• 关注对象原则：调用子类还是父类的方法，取决于创建的对象是子类对象还是父类对象，而不是它的引用类型。例如 Bird bird2 = new Chicken()时，我们关注的是其创建对象为Chicken类型，因此子类将继承父类的字段和方法，或者覆写父类的虚方法，而不用关注bird2的引 用类型是否为Bird。引用类型不同的区别决定了不同的对象在方法表中不同的访问权限。

• 执行就近原则：对于同名字段或者方法，编译器是按照其顺序查找来引用的，也就是首先访问离它创建最近的字段或者方法，例如上 例中的bird2，是Bird类型，因此会首先访问Bird_type（注意编译器是不会重新命名的，在此是为区分起见），如果type类型设为 public，则在此将返回“Bird”值。这也就是为什么在对象创建时必须将字段按顺序排列，而父类要先于子类编译的原因了。

4. 结论

　　本文讨论泛型使用的一般问题，比如为什么要使用泛型、泛型的编写方法、泛型中数据类型的约束、泛型中静态成员使用要注意的问题、泛型中方法重载的问、泛型方法等，通过这些使我们可以大致了解泛型并掌握泛型的一般应用，编写出更简单、通用、高效的应用系统。

　　什么是泛型

　　我们在编写程序时，经常遇到两个模块的功能非常相似，只是一个是处理int数据，另一个是处理string数据，或者其他自定义的数据类型，但我们没有办法，只能分别写多个方法处理每个数据类型，因为方法的参数类型不同。有没有一种办法，在方法中传入通用的数据类型，这样不就可以合并代码了吗？泛型的出现就是专门解决这个问题的。读完本篇文章，你会对泛型有更深的了解。

　　为什么要使用泛型

　　为了了解这个问题，我们先看下面的代码，代码省略了一些内容，但功能是实现一个栈，这个栈只能处理int数据类型： 

    public class Stack
    {
        private int[] m_item;
        public int Pop(){...}
        public void Push(int item){...}
        public Stack(int i)
        {
            this.m_item = new int[i];
        }
    } 字串7

　　上面代码运行的很好，但是，当我们需要一个栈来保存string类型时，该怎么办呢？很多人都会想到把上面的代码复制一份，把int改成string不就行了。当然，这样做本身是没有任何问题的，但一个优秀的程序是不会这样做的，因为他想到若以后再需要long、Node类型的栈该怎样做呢？还要再复制吗？优秀的程序员会想到用一个通用的数据类型object来实现这个栈：

    public class Stack
    {
        private object[] m_item;
        public object Pop(){...}
        public void Push(object item){...}

　        public Stack(int i)
        {
            this.m_item = new[i];
        }
    }

　　这个栈写的不错，他非常灵活，可以接收任何数据类型，可以说是一劳永逸。但全面地讲，也不是没有缺陷的，主要表现在：

1. 当Stack处理值类型时，会出现装箱、折箱操作，这将在托管堆上分配和回收大量的变量，若数据量大，则性能损失非常严重。
2. 在处理引用类型时，虽然没有装箱和折箱操作，但将用到数据类型的强制转换操作，增加处理器的负担。

　　在数据类型的强制转换上还有更严重的问题（假设stack是Stack的一个实例）：

        Node1 x = new Node1();
        stack.Push(x);
        Node2 y = (Node2)stack.Pop();

　　上面的代码在编译时是完全没问题的，但由于Push了一个Node1类型的数据，但在Pop时却要求转换为Node2类型，这将出现程序运行时的类型转换异常，但却逃离了编译器的检查。 

　　针对object类型栈的问题，我们引入泛型，他可以优雅地解决这些问题。泛型用用一个通过的数据类型T来代替object，在类实例化时指定T的类型，运行时（Runtime）自动编译为本地代码，运行效率和代码质量都有很大提高，并且保证数据类型安全。 

　　使用泛型

　　下面是用泛型来重写上面的栈，用一个通用的数据类型T来作为一个占位符，等待在实例化时用一个实际的类型来代替。让我们来看看泛型的威力：

    public class Stack<T>
    {
        private T[] m_item;
        public T Pop(){...}
        public void Push(T item){...}

　        public Stack(int i)
        {
            this.m_item = new T[i];
        }
    }

　　类的写法不变，只是引入了通用数据类型T就可以适用于任何数据类型，并且类型安全的。这个类的调用方法： 

    //实例化只能保存int类型的类

    Stack<int> a = new Stack<int>(100);
    a.Push(10);
    a.Push("8888"); //这一行编译不通过，因为类a只接收int类型的数据
    int x = a.Pop();

    //实例化只能保存string类型的类

    Stack<string> b = new Stack<string>(100);
    b.Push(10); //这一行编译不通过，因为类b只接收string类型的数据
    b.Push("8888");
    string y = b.Pop();

　　这个类和object实现的类有截然不同的区别： 

　　1. 他是类型安全的。实例化了int类型的栈，就不能处理string类型的数据，其他数据类型也一样。

　　2. 无需装箱和折箱。这个类在实例化时，按照所传入的数据类型生成本地代码，本地代码数据类型已确定，所以无需装箱和折箱。

　　3. 无需类型转换。

　　泛型类实例化的理论

　　C#泛型类在编译时，先生成中间代码IL，通用类型T只是一个占位符。在实例化类时，根据用户指定的数据类型代替T并由即时编译器（JIT）生成本地代码，这个本地代码中已经使用了实际的数据类型，等同于用实际类型写的类，所以不同的封闭类的本地代码是不一样的。按照这个原理，我们可以这样认为：

　　泛型类的不同的封闭类是分别不同的数据类型。

　　例：Stack<int>和Stack<string>是两个完全没有任何关系的类，你可以把他看成类A和类B，这个解释对泛型类的静态成员的理解有很大帮助。

　　泛型类中数据类型的约束

　　程序员在编写泛型类时，总是会对通用数据类型T进行有意或无意地有假想，也就是说这个T一般来说是不能适应所有类型，但怎样限制调用者传入的数据类型呢？这就需要对传入的数据类型进行约束，约束的方式是指定T的祖先，即继承的接口或类。因为C#的单根继承性，所以约束可以有多个接口，但最多只能有一个类，并且类必须在接口之前。这时就用到了C#2.0的新增关键字：

    public class Node<T, V> where T : Stack, IComparable
    where V: Stack
    {...} 

　　以上的泛型类的约束表明，T必须是从Stack和IComparable继承，V必须是Stack或从Stack继承，否则将无法通过编译器的类型检查，编译失败。

　　通用类型T没有特指，但因为C#中所有的类都是从object继承来，所以他在类Node的编写中只能调用object类的方法，这给程序的编写造成了困难。比如你的类设计只需要支持两种数据类型int和string，并且在类中需要对T类型的变量比较大小，但这些却无法实现，因为object是没有比较大小的方法的。 了解决这个问题，只需对T进行IComparable约束，这时在类Node里就可以对T的实例执行CompareTo方法了。这个问题可以扩展到其他用户自定义的数据类型。 

　　如果在类Node里需要对T重新进行实例化该怎么办呢？因为类Node中不知道类T到底有哪些构造函数。为了解决这个问题，需要用到new约束：

    public class Node<T, V> where T : Stack, new()
    where V: IComparable

　　需要注意的是，new约束只能是无参数的，所以也要求相应的类Stack必须有一个无参构造函数，否则编译失败。

　　C#中数据类型有两大类：引用类型和值类型。引用类型如所有的类，值类型一般是语言的最基本类型，如int, long, struct等，在泛型的约束中，我们也可以大范围地限制类型T必须是引用类型或必须是值类型，分别对应的关键字是class和struct:

    public class Node<T, V> where T : class
    where V: struct

　　泛型方法

　　泛型不仅能作用在类上，也可单独用在类的方法上，他可根据方法参数的类型自动适应各种参数，这样的方法叫泛型方法。看下面的类：

    public class Stack2
    {
        public void Push<T>(Stack<T> s, params T[] p)
        {
            foreach (T t in p)
            {
                s.Push(t);
            }
        }
    }

　　原来的类Stack一次只能Push一个数据，这个类Stack2扩展了Stack的功能（当然也可以直接写在Stack中），他可以一次把多个数据压入Stack中。其中Push是一个泛型方法，这个方法的调用示例如下： 

    Stack<int> x = new Stack<int>(100);
    Stack2 x2 = new Stack2();
    x2.Push(x, 1, 2, 3, 4, 6);

    string s = "";

    for (int i = 0; i < 5; i++)
    {
        s += x.Pop().ToString();
    } //至此，s的值为64321

　　泛型中的静态成员变量

　　在C#1.x中，我们知道类的静态成员变量在不同的类实例间是共享的，并且他是通过类名访问的。C#2.0中由于引进了泛型，导致静态成员变量的机制出现了一些变化：静态成员变量在相同封闭类间共享，不同的封闭类间不共享。

　　这也非常容易理解，因为不同的封闭类虽然有相同的类名称，但由于分别传入了不同的数据类型，他们是完全不同的类，比如：

    Stack<int> a = new Stack<int>();
    Stack<int> b = new Stack<int>();
    Stack<long> c = new Stack<long>();

　　类实例a和b是同一类型，他们之间共享静态成员变量，但类实例c却是和a、b完全不同的类型，所以不能和a、b共享静态成员变量。

　　泛型中的静态构造函数

　　静态构造函数的规则：只能有一个，且不能有参数，他只能被.NET运行时自动调用，而不能人工调用。 

　　泛型中的静态构造函数的原理和非泛型类是一样的，只需把泛型中的不同的封闭类理解为不同的类即可。以下两种情况可激发静态的构造函数：
    1. 特定的封闭类第一次被实例化。
    2. 特定封闭类中任一静态成员变量被调用。

　　泛型类中的方法重载

　　方法的重载在.Net Framework中被大量应用，他要求重载具有不同的签名。在泛型类中，由于通用类型T在类编写时并不确定，所以在重载时有些注意事项，这些事项我们通过以下的例子说明：

    public class Node<T, V>
    {
        public T add(T a, V b) //第一个add
        {
            return a;
        }
        public T add(V a, T b) //第二个add
        {
            return b;
        }
        public int add(int a, int b) //第三个add
        {
            return a + b;
        }
    }

　　上面的类很明显，如果T和V都传入int的话，三个add方法将具有同样的签名，但这个类仍然能通过编译，是否会引起调用混淆将在这个类实例化和调用add方法时判断。请看下面调用代码： 

    Node<int, int> node = new Node<int, int>();
    object x = node.add(2, 11);

　　这个Node的实例化引起了三个add具有同样的签名，但却能调用成功，因为他优先匹配了第三个add。但如果删除了第三个add，上面的调用代码则无法编译通过，提示方法产生的混淆，因为运行时无法在第一个add和第二个add之间选择。

    Node<string, int> node = new Node<string, int>();
    object x = node.add(2, "11");

　　这两行调用代码可正确编译，因为传入的string和int，使三个add具有不同的签名，当然能找到唯一匹配的add方法。

　　由以上示例可知，C#的泛型是在实例的方法被调用时检查重载是否产生混淆，而不是在泛型类本身编译时检查。同时还得出一个重要原则：

　　当一般方法与泛型方法具有相同的签名时，会覆盖泛型方法。

　　泛型类的方法重写

　　方法重写（override）的主要问题是方法签名的识别规则，在这一点上他与方法重载一样，请参考泛型类的方法重载。

　　泛型的使用范围

　　本文主要是在类中讲述泛型，实际上，泛型还可以用在类方法、接口、结构（struct）、委托等上面使用，使用方法大致相同，就不再讲述。

　　小结

　　C# 泛型是开发工具库中的一个无价之宝。它们可以提高性能、类型安全和质量，减少重复性的编程任务，简化总体编程模型，而这一切都是通过优雅的、可读性强的语法完成的。尽管 C# 泛型的根基是 C++ 模板，但 C# 通过提供编译时安全和支持将泛型提高到了一个新水平。C# 利用了两阶段编译、元数据以及诸如约束和一般方法之类的创新性的概念。毫无疑问，C# 的将来版本将继续发展泛型，以便添加新的功能，并且将泛型扩展到诸如数据访问或本地化之类的其他 .NET Framework 领域。 

ASP.NET 2.0的编译方式大体可以分成两种：动态编译和预编译，要回答为什么要进行预编译，我们先要看看动态编译有什么不好的地方。我们回顾一下上一篇介绍的 ASP.NET进行动态编译的简单的流程：当来自Brower的一个基于aspx的Http request抵达Web server，IIS handle这个request，通过分析注册在IIS中的Application Mapping，将Request 传给aspnet_isapi.dll ISAPI extension。ISAPI extension通过HttpRuntime进入Http Runtime Pipeline，HttpRuntime为每个Request创建一个单独的HttpContext对象，用于保存request的Context信 息。在Http Runtime Pipeline中，Http request会被注册的一系列的Http module处理，比如OutputCache Module，Session Module，Authentication Module，Authorization，ErrorHandler Module等等。在Pipeline的终端，ASP.NET需要需要根据request创建对应的HttpHandler对象来处理该Request， 并生成结果Response到Client。对于一个基于Aspx的Http request，对应的Http handler对象一般就是一个System.Web.UI.Page对象。

ASP.NET会先判断对应的Page type是否存在于被Cache的Assembly中，如果存在，直接创建Page对象，否则ASP.NET会先对该Page的相关的Source code (包括code behind，html等等) 进行编译，我们也说过这种编译是一Directory为单位的，也就是说，处于同一个Directory下的需要编译的文件会被编译成到同一个 Assembly中。编译生成的Assembly会被Cache，用于后续的Request。

正是因为对资源的首次访问会导致一次编译（这样 说不太准确，因为动态编译是以directory为单位进行的，应该对对某个Directory下的资源进行首次访问），这样会严重降低Web Application的响应速度。所以我们为了避免这种情况，需要预先对web site进行编译，所以提高web site的响应是进行预编译的最重要的原因。

同时动态编译就以为着Web server上放置的是Source code，而且他们是可被修改的。而对于一个开发完毕的Web Application，我们更希望以Binary Assembly的方式进行部署，这样Server上部署的都是Binary Assembly，不怕被别人篡改而导致系统的崩溃，从知识产权来讲，也更利于保护商业秘密。这也是我们为什么要进行预编译的另一个原因。

下面我们就来讲讲如何进行预编译，以及与编译背 后的原理。同时在这里我需要特别提出的是，在上一部分讲的一些术语和原理，比如Preservation file，FastObjectFactory，同样适用于预编译，重复的内容，在这里就不必再介绍了。同时我也将沿用上一部的Sample。如果想看看 相关的内容，请参阅[原创]深入剖析ASP.NET的编译原理之一：动态编译（Dynamical Compilation）。

2．In Place Pre-compilation V.S. Pre-compilation for Deployment

对于预编译，有可以分为In Place Pre-compilation和Pre-compilation for Deployment，In Place Pre-compilation很简单，实际上就是把整个Web site编译到我们一个临时的目录下面，这个临时目录也就是我们在介绍动态编译提到的那个临时目录。而且这个编译的方式，包括生成的文件也和动态编译完全 一样，唯一不同就是编译的时间：预先编译，编译的范围：整个Web site。这种编译就是你常用的在VS的build。这种编译方式一般用于开发阶段。

为了部署为目的的编译是我们今天讨论的重点，下面我们就着重来讨论Pre-compilation for Deployment。

注：在ASP.NET的编译都是通过一个叫做 aspnet_compiler的工具执行的，该工具随ASP.NET 2.0一起发布，你完全可以利用此工具以命令行的方式的执行编译，并通过传递不同的命令行开关设置不同的编译选项。该工具被置于了VS中，使你可以利用 VS进行可视化的编译。

3．Non-updatable Pre-compilation V.S. Updatable Pre-compilation

ASP.NET 2.0为我们提供了几种不同方式的预编译和部署。为了弄清楚这些预编译和部署方式，我们先来回顾一下ASP.NET 1.x下的编译方式。我们知道在ASP.NET 1.x时代对整个Web site进行编译，实际上我们只会对所有C#和VB.NET等后台代码进行编译，并生成一个单一的Assembly。而Web page的aspx是不会参与编译的。所以当我们访问一个Web page的时候，ASP.NET必须对aspx进行动态编译。

这一切之所以能够进行是因为Web page采用的是aspx + code behind的模式。

public partial class Default : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
    }
}

从上面我们可以看到aspx和Code behind是一种继承的关系，aspx继承和它对应的Code Behind。ASP.NET可以把Code behind和aspx分开进行编译，把它们编译到不同的Assembly中。我们就是上面的Code为例，

我们现在若对该Web site进行编译的话，Default.aspx.cs会被编译到一个Assembly中，假设这个Assembly为App_Web.dll. 我们把该Dll和aspx部署到Production Server上。如果我们现在访问defaut.aspx。ASP.NET

会对aspx进行动态编译，生成的Assembly可以暂时成为App_Web_aspx.dll。对于Default.aspx，如果我们如C#代码来描述的话，应该像下面一样定义：

public class default_aspx:Default
{
}

这种编译方式，我自己把它叫做对asXx的动态编译。 在ASP.NET2.0 中也沿用了这种编译方式。这种编译方式的主要特征是对Code behind和所有的后台代码进行预编余，aspx（确切地说应该是asXx：asax，asmx，asax等）原样部署。由于这种方式的预编译， asXx是可以修改的（当然这种修改是有一定限制的，因为code behind已经编译好了，所以这种修改只可能是和code behind无关的修改），所以又叫做Updatable Pre-compilation。

除了Updatable Pre-compilation之外，ASP.NET还提供另外一种高效的预编译方式，Non-updatable Pre-compilation，之所以叫做不可修改的预编译，这是因为：这种编译方式把asXx、Code behind、后台代码甚至是部分Resource都进行预编译，从而避免了运行时对asXx的动态编译，从而最大程度地提高了整个Web site的响应。在部署的时候，我们除了把生成的Assembly进行部署之外，所有的通过编译生成的asXx也必须进行部署。 不过需要特别说明的是，此时的asXx文件仅仅是一个占位的文件而已，它里面不具有任何HTML。

4．Partial class

在ASP.NET 1.x，由于采用的aspx + code behind的机制，对于任何一个Web page或者其他ASP.NET 基于axXx的对象来说，都是由两个文件、两个class组成。两个文件是指axXx和code behind，两个class是指Code behind定义的继承自System.Web.UI.Page的class，和一个继承自它的由axXx生成的class。

对于使用过ASP.NET 1.x来说，一定会很熟悉这样一种情况：对于每个在aspx中通过HTML定义的Server Control，在Code behind中必须具有一个对应的protected成员， 否则你不能通过编程的方式访问这个Server control。以不同方式呈现的同一个Server control通过ID关联起来，如果在Code behind中改了Server control的ID，Server control的Server端的Event handler将会失去原有的作用。

但是在ASP.NET 2.0来说，这种情况发生了改变，在aspx中的Server control在Code behind中却没有相应的成员变量，但是我们可以毫无障碍地访问到每个Server control。这使得我们的code behind更加简洁，通过避免了Server control在aspx和code bebind中的不匹配的问题。这一切都得益于.NET Framework 2.0提供的partial class的机制：把同一个class分布于不同文件中进行定义。有了这个概念，我们来看ASP.NET 2.0的code behind机制。

比如我们有这样的一个Page：

<%@ Page Language="C#" AutoEventWireup=