• 1. 通用类型系统
• 2. 值类型
• 3. 引用类型
• 4. 值类型和引用类型在内存中的部署
  • 4.1 数组在内存中的部署
  • 4.2 值类型和引用类型的嵌套
• 5. 正确使用值类型和引用类型
  • 5.1 辨明值类型和引用类型的使用场合
  • 5.2 将值类型尽可能实现为具有常量性和原子性的类型
  • 5.3 确保0为值类型的有效状态
  • 5.4 尽量减少装箱和拆箱
• 6. 总结
• 7. 参考

1. 通用类型系统

C#中，变量是值还是引用仅取决于其数据类型。

C#的基本数据类型都以平台无关的方式来定义。C#的预定义类型并没有内置于语言中，而是内置于.NET Framework中。.NET使用通用类型系统（CTS）定义了可以在中间语言（IL）中使用的预定义数据类型，所有面向.NET的语言都最终被编译为IL，即编译为基于CTS类型的代码。

例如，在C#中声明一个int变量时，声明的实际上是CTS中System.Int32的一个实例。这具有重要的意义：

• 确保IL上的强制类型安全；
• 实现了不同.NET语言的互操作性；
• 所有的数据类型都是对象。它们可以有方法，属性，等。例如：

int i;
i = 1;
string s;
s = i.ToString();

MSDN的这张图说明了CTS中各个类型是如何相关的。注意，类型的实例可以只是值类型或自描述类型，即使这些类型有子类别也是如此。

2. 值类型

C#的所有值类型均隐式派生自System.ValueType：

• 结构体：struct（直接派生于System.ValueType）；
  • 数值类型：
    • 整型：sbyte（System.SByte的别名），short（System.Int16），int（System.Int32），long（System.Int64），byte（System.Byte），ushort（System.UInt16），uint（System.UInt32），ulong（System.UInt64），char（System.Char）；
    • 浮点型：float（System.Single），double（System.Double）；
    • 用于财务计算的高精度decimal型：decimal（System.Decimal）。
  • bool型：bool（System.Boolean的别名）；
  • 用户定义的结构体（派生于System.ValueType）。
• 枚举：enum（派生于System.Enum）；
• 可空类型（派生于System.Nullable<T>泛型结构体，T?实际上是System.Nullable<T>的别名）。

每种值类型均有一个隐式的默认构造函数来初始化该类型的默认值。例如：

int i = new int();

等价于：

Int32 i = new Int32();

等价于：

int i = 0;

等价于：

Int32 i = 0;

使用new运算符时，将调用特定类型的默认构造函数并对变量赋以默认值。在上例中，默认构造函数将值0赋给了i。MSDN上有完整的默认值表。

关于int和Int32的细节，在我的另一篇文章中有详细解释：《理解C#中的System.Int32和int》。

所有的值类型都是密封（seal）的，所以无法派生出新的值类型。

值得注意的是，System.ValueType直接派生于System.Object。即System.ValueType本身是一个类类型，而不是值类型。其关键在于ValueType重写了Equals()方法，从而对值类型按照实例的值来比较，而不是引用地址来比较。

可以用Type.IsValueType属性来判断一个类型是否为值类型：

TestType testType = new TestType ();
if (testTypetype.GetType().IsValueType)
{
Console.WriteLine("{0} is value type.", testType.ToString());
}

3. 引用类型

C#有以下一些引用类型：

• 数组（派生于System.Array）
• 用户用定义的以下类型：
  • 类：class（派生于System.Object）；
  • 接口：interface（接口不是一个“东西”，所以不存在派生于何处的问题。Anders在《C# Programming Language》中说，接口只是表示一种约定[contract]）；
  • 委托：delegate（派生于System.Delegate）。
• object（System.Object的别名）；
• 字符串：string（System.String的别名）。

可以看出：

• 引用类型与值类型相同的是，结构体也可以实现接口；
• 引用类型可以派生出新的类型，而值类型不能；
• 引用类型可以包含null值，值类型不能（可空类型功能允许将 null 赋给值类型）；
• 引用类型变量的赋值只复制对对象的引用，而不复制对象本身。而将一个值类型变量赋给另一个值类型变量时，将复制包含的值。

对于最后一条，经常混淆的是string。我曾经在一本书的一个早期版本上看到String变量比string变量效率高；我还经常听说String是引用类型，string是值类型，等等。例如：

string s1 = "Hello, ";
string s2 = "world!";
string s3 = s1 + s2;//s3 is "Hello, world!"

这确实看起来像一个值类型的赋值。再如：

string s1 = "a";
string s2 = s1;
s1 = "b";//s2 is still "a"

改变s1的值对s2没有影响。这更使string看起来像值类型。实际上，这是运算符重载的结果，当s1被改变时，.NET在托管堆上为s1重新分配了内存。这样的目的，是为了将做为引用类型的string实现为通常语义下的字符串。

4. 值类型和引用类型在内存中的部署

经常听说，并且经常在书上看到：值类型部署在栈上，引用类型部署在托管堆上。实际上并没有这么简单。

MSDN上说：托管堆上部署了所有引用类型。这很容易理解。当创建一个应用类型变量时：

object reference = new object();

关键字new将在托管堆上分配内存空间，并返回一个该内存空间的地址。左边的reference位于栈上，是一个引用，存储着一个内存地址；而这个地址指向的内存（位于托管堆）里存储着其内容（一个System.Object的实例）。下面为了方便，简称引用类型部署在托管推上。

再来看值类型。《C#语言规范》上的措辞是“结构体不要求在堆上分配内存（However, unlike classes, structs are value types and do not require heap allocation）”而不是“结构体在栈上分配内存”。这不免容易让人感到困惑：值类型究竟部署在什么地方？

4.1 数组

考虑数组：

int[] reference = new int[100];

根据定义，数组都是引用类型，所以int数组当然是引用类型（即reference.GetType().IsValueType为false）。

而int数组的元素都是int，根据定义，int是值类型（即reference[i].GetType().IsValueType为true）。那么引用类型数组中的值类型元素究竟位于栈还是堆？

如果用WinDbg去看reference[i]在内存中的具体位置，就会发现它们并不在栈上，而是在托管堆上。

实际上，对于数组：

TestType[] testTypes = new TestType[100];

如果TestType是值类型，则会一次在托管堆上为100个值类型的元素分配存储空间，并自动初始化这100个元素，将这100个元素存储到这块内存里。

如果TestType是引用类型，则会先在托管堆为testTypes分配一次空间，并且这时不会自动初始化任何元素（即testTypes[i]均为null）。等到以后有代码初始化某个元素的时候，这个引用类型元素的存储空间才会被分配在托管堆上。

4.2 类型嵌套

更容易让人困惑的是引用类型包含值类型，以及值类型包含引用类型的情况：

public class ReferenceTypeClass
{
private int _valueTypeField;
public ReferenceTypeClass()
{
_valueTypeField = 0;
}
public void Method()
{
int valueTypeLocalVariable = 0;
}
}
ReferenceTypeClass referenceTypeClassInstance = new ReferenceTypeClass();//Where is _valueTypeField?
referenceTypeClassInstance.Method();//Where is valueTypeLocalVariable?
public struct ValueTypeStruct
{
private object _referenceTypeField;
public ValueTypeStruct()
{
_referenceTypeField = new object();
}
public void Method()
{
object referenceTypeLocalVariable = new object();
}
}
ValueTypeStruct valueTypeStructInstance = new ValueTypeStruct();//Where is _referenceTypeField？
valueTypeStructInstance.Method();//Where is referenceTypeLocalVariable?

单看valueTypeStructInstance，这是一个结构体实例，感觉似乎是整块扔到栈上的。但是字段_referenceTypeField是引用类型，局部变量referenceTypeLocalVarible也是引用类型。

referenceTypeClassInstance也有同样的问题，referenceTypeClassInstance本身是引用类型，似乎应该整块部署在托管堆上。但字段_valueTypeField是值类型，局部变量valueTypeLocalVariable也是值类型，它们究竟是在栈上还是在托管堆上？

规律是：

• 引用类型部署在托管堆上；
• 值类型总是分配在它声明的地方：作为字段时，跟随其所属的变量（实例）存储；作为局部变量时，存储在栈上。

我们来分析一下上面的代码。对于引用类型实例，即referenceTypeClassInstance：

• 从上下文看，referenceTypeClassInstance是一个局部变量，所以部署在托管堆上，并被栈上的一个引用所持有；
• 值类型字段_valueTypeField属于引用类型实例referenceTypeClassInstance的一部分，所以跟随引用类型实例referenceTypeClassInstance部署在托管堆上（有点类似于数组的情形）；
• valueTypeLocalVariable是值类型局部变量，所以部署在栈上。

而对于值类型实例，即valueTypeStruct：

• 根据上下文，值类型实例valueTypeStructInstance本身是一个局部变量而不是字段，所以位于栈上；
• 其引用类型字段_referenceTypeField不存在跟随的问题，必然部署在托管堆上，并被一个引用所持有（该引用是valueTypeStruct的一部分，位于栈）；
• 其引用类型局部变量referenceTypeLocalVariable显然部署在托管堆上，并被一个位于栈的引用所持有。

所以，简单地说“值类型存储在栈上，引用类型存储在托管堆上”是不对的。必须具体情况具体分析。

5. 正确使用值类型和引用类型

这一部分主要参考《Effective C#》，并非本人原创，希望能让你加深对值类型和引用类型的理解。

5.1 辨明值类型和引用类型的使用场合

C#中，我们用struct/class来声明一个类型为值类型/引用类型。

考虑下面的例子：

TestType[] testTypes = new TestType[100];

如果TestTye是值类型，则只需要一次分配，大小为TestTye的100倍。而如果TestTye是引用类型，刚开始需要100次分配，分配后数组的各元素值为null，然后再初始化100个元素，结果总共需要进行101次分配。这将消耗更多的时间，造成更多的内存碎片。所以，如果类型的职责主要是存储数据，值类型比较合适。

一般来说，值类型（不支持多态）适合存储供 C#应用程序操作的数据，而引用类型（支持多态）应该用于定义应用程序的行为。

通常我们创建的引用类型总是多于值类型。如果以下问题的回答都为yes，那么我们就应该创建为值类型：

• 该类型的主要职责是否用于数据存储？
• 该类型的共有借口是否完全由一些数据成员存取属性定义？
• 是否确信该类型永远不可能有子类？
• 是否确信该类型永远不可能具有多态行为？

5.2 将值类型尽可能实现为具有常量性和原子性的类型

具有常量性的类型很简单：

• 如果构造的时候验证了参数的有效性，之后就一直有效；
• 省去了许多错误检查，因为禁止更改；
• 确保线程安全，因为多个reader访问到同样的内容；
• 可以安全地暴露给外界，因为调用者不能更改对象的内部状态。

具有原子性的类型都是单一的实体，我们通常会直接替换一个原子类型的整个内容。

下面是一个典型的可变类型：

public struct Address
{
private string _city;
private string _province;
private int _zipCode;
public string City
{
get { return _city; }
set { _city = value; }
}
public string Province
{
get { return _province; }
set
{
ValidateProvince(value);
_province = value;
}
}
public int ZipCode
{
get { return _zipCode; }
set
{
ValidateZipCode(value);
_zipCode = value;
}
}
}

下面创建一个实例：

Address address = new Address();
address.City = "Chengdu";
address.Province = "Sichuan";
address.ZipCode = 610000;

然后更改这个实例：

address.City = "Nanjing"; //Now Province and ZipCode are invalid
address.ZipCode = 210000; //Now Province is still invalid
address.Province = "Jiangsu";

可见，内部状态的改变意味着可能违反对象的不变式（invariant），至少是临时的违反。如果上面是一个多线程的程序，那么在 City更改的过程中，另一个线程可能看到不一致的数据视图。如果不是多线程的程序，也有问题：

• 当ZipCode的值无效而抛出异常时，对象仅作了一部分改变，因此处于无效的状态，为了修复这个问题，需要在Address中添加相当多的内部校验代码；
• 为了实现异常安全，我们需要在所有改变多个字段的客户代码处放上防御性的代码；
• 线程安全也要求我们在每一个属性的访问器上添加线程同步检查。

显然，这是一个相当可观的工作量。下面我们把Address实现为常量类型：

public struct Address
{
private string _city;
private string _province;
private int _zipCode;
public Address (string city, string province, int zipCode)
{
_city = city;
_province = province;
_zipCode = zipCode;
ValidateProvince(province);
ValidateZipCode(zipCode);
}
public string City
{
get { return _city; }
}
public string Province
{
get { return _province; }
}
public int ZipCode
{
get { return _zipCode; }
}
}

如果要改变Address，不能修改现有的实例，只能创建一个新的实例：

Address address = new Address("Chengdu", "Sichuan", 610000);//create a instance
address = new Address("Nanjing", "Jiangsu", 210000);//modify the instance

address将不存在任何无效的临时状态。那些临时状态只存在于Address的构造函数执行过程中。这样一来，Address是异常安全的，也是线程安全的。

5.3 确保0为值类型的有效状态

.NET的默认初始化机制会将引用类型设置为二进制意义上的0，即null。而对于值类型，不论我们是否提供构造函数，都会有一个默认的构造函数，将其设置为0。

一种典型的情况是枚举：

public enum Sex
{
Male = 1;
Female = 2;
}

然后用做值类型的成员：

public struct Employee
{
private Sex _sex;
//other
}

创建Employee结构体将得到一个无效的Sex字段：

Employee employee = new Employee ();

employee的_sex是无效的，因为其为0。我们应该将0作为一个为初始化的值明确表示出来：

public Sex
{
None = 0;
Male = 1;
Female = 2;
}

如果值类型中包含引用类型，会出现另一种初始化问题：

public struct ErrorLog
{
private string _message;
//other
}

然后创建一个ErrorLog：

ErrorLog errorLog = new ErrorLog ();

errorLog的_message字段将是一个空引用。我们应该通过一个属性来将_message暴露给客户代码，从而使该问题限定在ErrorLog 的内部：

public struct ErrorLog
{
private string _message;
public string Message
{
get
{
return (_message ! = null) ? _message : string.Empty;
}
set { _message = value; }
}
//other
}

5.4 尽量减少装箱和拆箱

装箱指把一个值类型放入一个未具名类型的引用类型中，比如：

int valueType = 0;
object referenceType = i;//boxing

拆箱则是从前面的装箱对象中取出值类型：

object referenceType;
int valueType = (int)referenceType;//unboxing

装箱和拆箱是比较耗费性能的，还会引入一些诡异的bug，我们应当避免装箱和拆箱。

装箱和拆箱最大的问题是会自动发生。比如：

Console.WriteLine("A few numbers: {0}, {1}.", 25, 32);

其中，Console.WriteLine()接收的参数类型是(string，object，object)。因此，实际上会执行以下操作：

int i = 25;
obeject o = i;//boxing

然后把o传给WriteLine()方法。在WriteLine()方法的内部，为了调用i上的ToString()方法，又会执行：

int i = (int)o;//unboxing
string output = i,ToString();

所以正确的做法应该是：

Console.WriteLine("A few numbers: {0}, {1}.", 25.ToString(), 32.ToString());

25.ToString()只是执行一个方法并返回一个引用类型，不存在装箱/拆箱的问题。

另一个典型的例子是ArryList的使用：

public struct Employee
{
private string _name;
public Employee(string name)
{
_name = name;
}
public string Name
{
get { return _name; }
set { _name = value; }
}
public override string ToString()
{
return _name;
}
}
ArrayList employees = new ArrayList();
employees.Add(new Employee("Old Name"));//boxing
Employee ceo = (Employee)employees[0];//unboxing
ceo.Name = "New Name";//employees[0].ToString() is still "Old Name"

上面的代码不仅存在性能的问题，还容易导致错误发生。

在这种情况下，更好的做法是使用泛型集合：

List<Employee> employees = new List<Employee>();

由于List<T>是强类型的集合，employees.Add()方法不进行类型转换，所以不存在装箱/拆箱的问题。

6. 总结

C#中，变量是值还是引用仅取决于其数据类型。

C#的值类型包括：结构体（数值类型，bool型，用户定义的结构体），枚举，可空类型。

C#的引用类型包括：数组，用户定义的类、接口、委托，object，字符串。

数组的元素，不管是引用类型还是值类型，都存储在托管堆上。

引用类型在栈中存储一个引用，其实际的存储位置位于托管堆。为了方便，本文简称引用类型部署在托管推上。

值类型总是分配在它声明的地方：作为字段时，跟随其所属的变量（实例）存储；作为局部变量时，存储在栈上。

值类型在内存管理方面具有更好的效率，并且不支持多态，适合用作存储数据的载体；引用类型支持多态，适合用于定义应用程序的行为。

应该尽可能地将值类型实现为具有常量性和原子性的类型。

应该尽可能地确保0为值类型的有效状态。

应该尽可能地减少装箱和拆箱。

 public class Node
    {
        private Node left;
        private Node right;
        private int value;

        public Node(Node left, Node right, int value)
        {
            this.left = left;
            this.right = right;
            this.value = value;
        }

        public Node(int value)
        {
            this.value = value;
        }

        public Node getLeftNode() { return left; }
        public Node getRightNode() { return right; }
        public int getValue() { return value; }

从笔者接触编程至今，经历了数种编程语言，从Visual Basic6.0桌面程序开发到ASP(VBScript)的网站开发，从C#1.1到C#2.0，再至今日的令人加心动的C#3.5，笔者曾多次为Windows平台下的编程感慨——越来越方便的操作，越来越强大的功能，越来越简洁的代码使得由代码组成的编程世界中平添的许多色彩与欢乐。

以上可以算作对即将要介绍的C#3.5新特性的一个铺垫。笔者对于C#的爱，胜过其他的任何语言，尤其对于刚刚召开不久的微软2008新技术大会上发布的Visual Studio 2008笔者的爱意更甚。于是，笔者决定将自己对它的爱以文章的形式来表达。

让我们去由此开始，向C#3.5示爱：

一、告诉C#3.5，我们对爱上它的暧昧－var关键字

暧昧？众所周知，C#从出生以来都是很以一种强类型的语言示人的，并不像JavaScript和VB6.0那样给人以“暧昧”的感觉啊？而在此处介绍的关键字var，是否让您想起了JavaScript中的定义变量的关键字var？事实上，这两个看似相同的关键字却有本质上的区别。而这个var关键字并非在C#3.5中才出现的，它在C#3.0中便已经存在，笔者之所以在此介绍它，是因为欲介绍3.5，必须而且应该去介绍一下这个在C#3.0中便出现的特性——本地类型推断(Local Type Reference)，如若不然，笔者内心便无法安稳。

在C#2.0及其以前的版本中，如若定义一可以向其赋任何值的变量，那么我们需对其以object关键字进行定义，这种变量需要对值类型的进行装箱操作而且在对该变量使用的时候还需要进行相应的拆箱操作，而这种装箱拆箱所耗费的资源实在是笔者所不愿意看到的。

那么，我们既不愿意编写无谓耗费资源的代码，又想去实现object定义变量实现的功能，怎么办？C#3.5为我们提供了一种变量定义方式：

（图1，1.jpg）

看上面的变量定义，奇怪么？其实这就是C#3.5为我们提供的一种新功能——本地类型推断，它可以保护类型安全，而且允许您编写更为“自由”的代码。也就是说，我们可以不去考虑变量的类型而直接以var关键字去修饰它，编译器能够从给变量赋值的表达式中智能推断出变量的类型。它和COM模型中的Variant关键字定义出的变量完全不同，COM中的Variant关键字是后期绑定的一种方式，在编译期没有检测，仅在代码运行时才会出现它自身存在的问题，而且一不小心就会出现一大堆令人讨厌的Bug。而C#中这个var定义的变量在编译其便推断出它的类型，并且编译后的IL代码中只包含推断出的类型。

即上面的两行代码完全等同物如下代码：

（图二，2.jpg）

那么，既然二者等同，我们为什么还要对它的这种“暧昧”情有独衷？事实上，var关键字不仅仅能够实现我们如上所述的功能，它会成为你在使用C#3.5进行编程时非常熟悉的一个朋友，记住这个“匿名类型(Anonymous Type)”，也记住这个“本地类型推断(Local Type Reference)”。

二、告诉C#3.5，我们喜欢它纤细的身材——自动属性(Automatic Properties)

还记得我们在C#1.1和C#2.0写类的属性时定义的那个小小的私有变量么？甚至有些人还因为私有变量是否应该和属性定义在一起而展开了争论。那么，现行社会流行的“减肥”这个词也可以应用到我们的程序代码上来。

C#3.5为我们提供了自动属性(Automatic Properties),看如下代码：

（图三，3.jpg）

很奇怪么？get和set关键字均没有我们以前所熟悉的return value;和_privateField=value;这样的字眼。事实上，这就是我们的这善解人意的代码编译器为我们提供的最新功能自动属性。编译器会为我们定义的Name属性自动生成一私有变量来保存其值。于是，我们原来需要至少三行才能完成的代码现在仅需一行便轻松完成了。

不过，它有自身的局限性，比如说不能在用自动属性定义的属性中加逻辑判断，get和set必须成对出现等。然而，笔者相信并非我们所有的属性均要加上逻辑判断吧？那么，就请去尝试自动属性为我们带来的便利。

三、奇怪的“=>”符号——lambda表达式

习惯C#编程的您在C#2.0及其以前见到过这个符号”=>”么？这又是一新特性，我们可以将它读作”lambda表达式”。

C# 2.0 通用使用匿名方法引入了"传递指针到特定代码"作为参数的功能。这是一个功能强大的概念，但是这种方式您实际传递的是方法的一个指针，而不是代码块。那个引用指向编译时生成的强类型代码。使用泛型，您可获得更大灵活性，但是对泛型类型难以应用标准操作符 。C# 3.0 引入 lambda 表达式，它允许使用更简练的语法来定义匿名方法。

看如下代码片断：

（图四，4.jpg）

且不说其他部分意义，单来看我们.Where括号之中的部分,c=>c.Address==City.Heze这段代码，我们可以将它理解为，给定c，返回c.Address==City.Heze的记录集，此处就是lambda表达式的应用之一，它广泛应用于我们下期即将介绍的LINQ(Language Integerated Query)中。

四、为我们的爱加上更为自由的翅膀——扩展方法

熟知Web编程的朋友们应该对如下这段代码很熟悉：

（图五，5.jpg）

其中ReplaceUnSafeChars是一个进行字符器过滤的函数，将传入的字符串中的非法字符过滤，返回一合法的字符串，它通常用于用户向某一数据处理页面提交数据时，为了防止SQL注入或者其他非法入侵而进行的一项工作。为此我们不厌其烦地写类库，在某一项目的解决方案中添加进来自己过滤函数。这种方式是不错，可是，能不能有一种方式让我们更为方便，让我们写出的代码更为优雅？

设想，如果我们能够对系统中定义的数据类型进行扩展，给它增加上我们自己的方法，那岂不是我们可以像strID.ToSring()那样来实现我们自己的过滤方法？

不错，想法有了，自然C#也不会让我们失望——扩展方法(Extension Methods)为我们来解决这一问题。如下图我们定义一个类：

（图六，6.jpg）

注意，该类为静态类，并且其中的方法Name为静态方法，其参数o为object类型，并且有关键字this进行修饰。以上这些，就是为系统类型进行扩展时的必备条件。在定义了该类的同一命名空间下的其他类中即可对所有类型使用该Name方法来获取它的ToString()之后的值。我们看编译器是如何来表示的：

（图7，7.jpg）

我们看到，编译器强大的智能提示功能给我们的提示是(extension) string object.Name()，这是因为我们是对object类进行了扩展，故我们可以对任何类型使用扩展方法Name。

这虽然并不是一个十分大的改动，可是对于我们在代码上的可读性及实用性都会有很大的帮助。我们习惯了从左到右的阅读方式，习惯了在打”.”时编译器给出智能提示，所以我们也会毫无理由的习惯“扩展方法”。

要注意，对于值类型的变量进行扩展是MS推荐的，可是对于引用类型的变量进行扩展却并未被推荐，因为对于所有的调用都要创建一个对象的拷贝，而这个对象拷贝的创建的花销是我们所不敢随意忽略的。

五、令人心动的LINQ

您想过在代码中不写SQL语句就实现对数据库的操作么？当然，笔者并不是指那种通过拖拽数据源控件如SQLDataSource等然后加个GridView或者FormView就去实现对数据的显示、更新的操作。假如有一种工具能够让将我们数据库中的表映射为对象，而且映射这一工作能够自动完成，然后我们就可以通过对这些映射过来的对象进行操作，从而实现对数据表的操作了。

正如笔者上面所说，想法有了，就可以实现。事实上，LINQ并不是属于C#的，更不能说是C#3.5的特性了。不过笔者在这里提出，主要是因为它实在太令人兴奋而且C#3.5中的编程如果没有了对LINQ的使用代码就会逊色许多。

上述两段作为您的“开胃菜”，仅令您心动是远远不够的，让我们近距离接触一下LINQ——语言集成查询(Language Integerated Query)。

笔者以LINQ对数据库的操作来对LINQ做一下大概的介绍。

LINQ to SQL 是O/RM(对象关系映射）在.NET Framework（Visual Studio 2008）中的的一种实现，它允许你用.NET 的类来生成一个关系型的数据库。然后你可以用LINQ对从该对象中对数据库进行查询，更新/插入/删除。

LINQ to SQL完全支持事务，视图和存储过程。它还提供了一种方便地在你的数据模型中对集合数据验证和业务逻辑规则的进行验证的方法。

它的基本语法from… in..select是显得如此优雅，令我不得不为其用如此简洁的代码实现我们以往需要写数行甚至数十行才能够实现的功能感到兴奋。还记得我们在上面介绍“=>”lambda表达式时提供的那个小例子么？

（图8，8.jpg）

这就是最简单的LINQ实现。其中customers可以是我们从数据库中映射过来的对象，也可以是我们自己定义的某类的实例。它实现的功能是从customers对象实例中查找出所有的Address为Heze的实例，返回值IEnumerable<Customer>类型。LINQ可以实现对所有实现了IEnumuerable接口的对象进行查询

事实上，LINQ不仅可以to DataSet,也不仅可以to SQL,也不仅可以to XML,笔者认为，LINQ是可以to Everything的。

六 结语

以上仅仅是给笔者很大触动并且打动了笔者心的若干功能的一部分，限于篇幅笔者不能一一进行展开，望读者见谅。笔者将在后续的文章中与您分享更多的知识与经验。

我曾经无数次地思考，自己现在到过的到底是一种什么样的生活，而自己的理想，又在何方。这些思考使得我经常感觉身心疲惫——虽然，自己才刚二十出头。这种日子，使我对于亲情，对于友情变得麻木，以至于忘记了父亲的生日。

为了能够在父亲生日这一天给他打个电话问候一下，我特地用手机定了一个今天早晨5：30的备忘录。我怕自己忘记，于是昨晚睡觉前特地叮嘱自己，明天早晨一定要记起这件事。就像我高三时在每个晚上睡觉前都告诉自己第二天早晨一定要早起一样虔诚。

心中有事时，我在睡觉时会特别的警觉。一哥们的闹钟响了，一个不知听了多少遍的闹钟铃声“翻开寂寞的旧抽屉，我又看到了你写的诗……”。我拿起手机，看看时间，是早晨五点。

我拨通了家里的电话号码，响了若干次，电话通了。

“爸，起床了么？”我问。

“起来了，一会得去干活了”，父亲的声音传来。

……

我没有特意的去说什么爸爸生日快乐之类话，也说不出口。也许是环境，也许是习惯。从小到大，我对父母表达自己的爱时，从不会像电视中那样对父母说：“爸妈我爱你”。我所做的，是与父母聊聊天，说说家里的事，说说父母的身体，说说家里的天气，说说村里有什么变化，说说家里的喂养的那几只小羊，还有那只可爱的小猫，和那只被我驯服的了黑狗……在和父母拉家常时，是我最快乐的时候，能记我忘却许多的烦恼。

有的时候翻开高中时写的一些作文，关于父亲的，关于母亲的，会觉得是如此的怀念。翻开高中时给父母写的信，还有父母写给我的，觉得是如此的亲切。上大学的四年中，我能数得过来给父母写信的次数，也许，是因为有电话了的缘故？

五点钟，我想城里人还在沉睡。我也是，虽然我不是城里人。而父亲，已经早早地起床……

我想对父亲说：“爸，今天别去了，在家休息一天”，可我又觉得这话是如此的不好出口。家中的情形，我能够明白。于是我只能默默的以心中为父亲祈祷，不要太累，晚上不要回家太晚，清晨不要起床太早。

思绪飘飞，我想起了上初中时的情景。每天早晨五点钟，和村里的几个要好的小伙伴一起去上学。然后父母也起床，开始忙碌的一天。唉，算了，往事，不想再去回忆。

我想起高中时的作文上写：“父爱如山”，经历了这许多事，才对这个比喻有了一点似乎明白了的意思，父爱，像山一样的巍峨，像山一样的沉稳，也像山一样的雄伟。山立在那里，一言不发，可是你却能从它身上读懂许多的道理。你可以在心情不好时到大山中去大喊，去发泄，去倾诉，也可以在心情阳光时到大山中去大喊，去喊出心中的快乐与激情。无论你对它如何撒娇，如何发怒，山，始终威严的立着，包容着你的一切。

生活，依旧是生活。父亲依旧是父亲，只是岁月，却已经无情的轧过父亲的额头与双手。

 “爸，让我妈给你做点好吃的”。

“吃了吃了，前天你妈都已经给我做了”——

我无语，想着父亲，也想着母亲，心中有泪，可表现出来的，只能是坚强。要不，会有人说我像小孩儿。

我不是诗人，所以不能为父亲写诗，

我也不是作家，所以也不能为父亲写出精彩的篇章。

我只能用心，用情感，去组织一些胸中涌动的文字，拼凑出一篇能够表达我内心的文章来。

父亲能够听到，我在心中为他唱的这首歌——

那是我小时候
常坐在父亲肩头
父亲是儿那登天的梯
父亲是那拉车的牛
忘不了粗茶淡饭将我养大
忘不了一声长叹半壶老酒
等我长大后
山里孩子往外走
想儿时一封家书千里写叮嘱
盼儿归一袋闷烟满天数星斗
都说养儿能防老
可儿山高水远他乡留
都说养儿为防老
可你再苦再累不张口
儿只有清歌一曲和泪唱
愿天下父母平安度春秋

那是我小时候
常坐在父亲肩头
父亲是儿那登天的梯
父亲是那拉车的牛
忘不了粗茶淡饭将我养大
忘不了一声长叹半壶老酒