C语言教程~适合于初学者

我们不能孤立地使用C#语言，而必须和.NET Framework一起考虑。C#编译器专门用于.NET，这表示用C#编写的所有代码总是在.NET Framework中运行。对于C#语言来说，可以得出两个重要的结论：

●       C#的结构和方法论反映了.NET基础方法论。

●       在许多情况下，C#的特定语言功能取决于.NET的功能，或依赖于.NET基类。

由于这种依赖性，在开始使用C#编程前，了解.NET的结构和方法论就非常重要了，这就是本章的目的。

本章首先了解在.NET编译和运行所有的代码(包括C#)时通常会出现什么情况。对这些内容进行概述之后，就要详细阐述Microsoft中间语言(Microsoft Intermediate Language，MSIL或简称为IL)，所有编译好的代码都要使用这种语言。本章特别要介绍IL、通用类型系统(Common Type System，CTS)及公共语言规范(Common Language Specification，CLS)如何提供.NET语言之间的互操作性。最后解释各种语言如何使用.NET，包括Visual Basic和C++。

之后，我们将介绍.NET的其他特性，包括程序集、命名空间和.NET基类。最后本章简要探讨一下C#开发人员可以创建的应用程序类型。

1.1  C#与.NET的关系

C#是一种相当新的编程语言，C#的重要性体现在以下两个方面：

●       它是专门为与Microsoft的.NET Framework一起使用而设计的。(.NET Framework是一个功能非常丰富的平台，可开发、部署和执行分布式应用程序)。

●       它是一种基于现代面向对象设计方法的语言，在设计它时，Microsoft还吸取了其他类似语言的经验，这些语言是近20年来面向对象规则得到广泛应用后才开发出来的。

有一个很重要的问题要弄明白：C#就其本身而言只是一种语言，尽管它是用于生成面向.NET环境的代码，但它本身不是.NET的一部分。.NET支持的一些特性，C#并不支持。而C#语言支持的另一些特性，.NET却不支持(例如运算符重载)！

但是，因为C#语言是和.NET一起使用的，所以如果要使用C#高效地开发应用程序，理解Framework就非常重要，所以本章将介绍.NET的内涵。

1.2  公共语言运行库

.NET Framework的核心是其运行库的执行环境，称为公共语言运行库(CLR)或.NET运行库。通常将在CLR的控制下运行的代码称为托管代码(managed code)。

但是，在CLR执行开发的源代码之前，需要编译它们(在C#中或其他语言中)。在.NET中，编译分为两个阶段：

(1) 把源代码编译为Microsoft中间语言(IL)。

(2) CLR把IL编译为平台专用的代码。

这个两阶段的编译过程非常重要，因为Microsoft中间语言(托管代码)是提供.NET的许多优点的关键。

托管代码的优点

Microsoft中间语言与Java字节代码共享一种理念：它们都是一种低级语言，语法很简单(使用数字代码，而不是文本代码)，可以非常快速地转换为内部机器码。对于代码来说，这种精心设计的通用语法，有很重要的优点。

1. 平台无关性

首先，这意味着包含字节代码指令的同一文件可以放在任一平台中，运行时编译过程的最后阶段可以很容易完成，这样代码就可以运行在该特定的平台上。换言之，编译为中间语言就可以获得.NET平台无关性，这与编译为Java字节代码就会得到Java平台无关性是一样的。

注意.NET的平台无关性目前只是一种可能，因为在编写本书时，.NET只能用于Windows平台，但人们正在积极准备，使它可以用于其他平台(参见Mono项目，它用于创建.NET的开放源代码的实现，参见http://www.go-mono.com/)。

2. 提高性能

前面把IL和Java做了比较，实际上，IL比Java字节代码的作用还要大。IL总是即时编译的(称为JIT编译)，而Java字节代码常常是解释性的，Java的一个缺点是，在运行应用程序时，把Java字节代码转换为内部可执行代码的过程会导致性能的损失(但在最近，Java在某些平台上能进行JIT编译)。

JIT编译器并不是把整个应用程序一次编译完(这样会有很长的启动时间)，而是只编译它调用的那部分代码(这是其名称由来)。代码编译过一次后，得到的内部可执行代码就存储起来，直到退出该应用程序为止，这样在下次运行这部分代码时，就不需要重新编译了。Microsoft认为这个过程要比一开始就编译整个应用程序代码的效率高得多，因为任何应用程序的大部分代码实际上并不是在每次运行过程中都执行。使用JIT编译器，从来都不会编译这种代码。

这解释了为什么托管IL代码的执行几乎和内部机器代码的执行速度一样快，但是并没有说明为什么Microsoft认为这会提高性能。其原因是编译过程的最后一部分是在运行时进行的，JIT编译器确切地知道程序运行在什么类型的处理器上，可以利用该处理器提供的任何特性或特定的机器代码指令来优化最后的可执行代码。

传统的编译器会优化代码，但它们的优化过程是独立于代码所运行的特定处理器的。这是因为传统的编译器是在发布软件之前编译为内部机器可执行的代码。即编译器不知道代码所运行的处理器类型，例如该处理器是x86兼容处理器还是Alpha处理器，这超出了基本操作的范围。例如Visual Studio 6为一般的Pentium机器进行了优化，所以它生成的代码就不能利用Pentium III处理器的硬件特性。相反，JIT编译器不仅可以进行Visual Studio 6所能完成的优化工作，还可以优化代码所运行的特定处理器。

3. 语言的互操作性

使用IL不仅支持平台无关性，还支持语言的互操作性。简言之，就是能将任何一种语言编译为中间代码，编译好的代码可以与从其他语言编译过来的代码进行交互操作。

那么除了C#之外，还有什么语言可以通过.NET进行交互操作呢？下面就简要讨论其他常见语言如何与.NET交互操作。

(1) Visual Basic 2005

Visual Basic 6在升级到Visual Basic .NET 2002时，经历了一番脱胎换骨的变化，才集成到.NET Framework的第一版中。Visual Basic 语言对Visual Basic 6进行了很大的演化，也就是说，Visual Basic 6并不适合运行.NET程序。例如，它与COM的高度集成，且只把事件处理程序作为源代码显示给开发人员，大多数后台代码不能用作源代码。另外，它不支持继承，Visual Basic使用的标准数据类型也与.NET不兼容。

Visual Basic 6在2002年升级为Visual Basic .NET，对Visual Basic进行的改变非常大，完全可以把Visual Basic当作是一种新语言。现有的Visual Basic 6代码不能编译为Visual Basic 2005代码(或Visual Basic .NET 2002和2003代码)，把Visual Basic 6程序转换为Visual Basic 2005时，需要对代码进行大量的改动，但大多数修改工作都可以由Visual Studio 2005(Visual Studio的升级版本，用于与.NET一起使用)自动完成。如果要把一个Visual Basic 6项目读取到Visual Studio 2005中，Visual Studio 2005就会升级该项目，也就是说把Visual Basic 6源代码重写为Visual Basic 2005源代码。虽然这意味着其中的工作已大大减轻，但用户仍需要检查新的Visual Basic 2005代码，以确保项目仍可正确工作，因为这种转换并不十分完美。

这种语言升级的一个副作用是不能再把Visual Basic 2005编译为内部可执行代码了。Visual Basic 2005只编译为中间语言，就像C#一样。如果需要继续使用Visual Basic 6编写程序，就可以这么做，但生成的可执行代码会完全忽略.NET Framework，如果继续把Visual Studio作为开发环境，就需要安装Visual Studio 6。

(2) Visual C++ 2005

Visual C++ 6有许多Microsoft对Windows的特定扩展。通过Visual C++ .NET，又加入了更多的扩展内容，来支持.NET Framework。现有的C++源代码会继续编译为内部可执行代码，不会有修改，但它会独立于.NET运行库运行。如果要让C++代码在.NET Framework中运行，就要在代码的开头添加下述命令：

#using <mscorlib.dll>

还可以把标记/clr传递给编译器，这样编译器假定要编译托管代码，因此会生成中间语言，而不是内部机器码。C++的一个有趣的问题是在编译托管代码时，编译器可以生成包含内嵌本机可执行代码的IL。这表示在C++代码中可以把托管类型和非托管类型合并起来，因此托管C++代码：

class MyClass

{

定义了一个普通的C++类，而代码：

__gc class MyClass

{

生成了一个托管类，就好像使用C#或Visual Basic 2005编写类一样。实际上，托管C++比C#更优越的一点是可以在托管C++代码中调用非托管C++类，而不必采用COM交互功能。

如果在托管类型上试图使用.NET不支持的特性(例如，模板或类的多继承)，编译器就会出现一个错误。另外，在使用托管类时，还需要使用非标准的C++特性(例如上述代码中的__gc关键字)。

因为C++允许低级指针操作，C++编译器不能生成可以通过CLR内存类型安全测试的代码。如果CLR把代码标识为内存类型安全是非常重要的，就需要用其他一些语言编写源代码，例如C# 或Visual Basic 2005。

(3) Visual J# 2005

最新添加的语言是Visual J# 2005。在.NET Framework 1.1版本推出之前，用户必须下载相应的软件，才能使用J#。现在J#语言内置于.NET Framework中。因此，J#用户可以利用Visual Studio 2005的所有常见特性。Microsoft希望大多数J++用户认为他们在使用.NET时，将很容易使用J#。J#不使用Java运行库，而是使用与其他.NET兼容语言一样的基类库。这说明，与C#和Visual Basic 2005一样，可以使用J#创建ASP.NET Web应用程序、Windows窗体、XML Web服务和其他应用程序。

(4) 脚本语言

脚本语言仍在使用之中，但由于.NET的推出，一般认为它们的重要性在降低。另一方面，JScript升级到JScript.NET。现在ASP.NET页面可以用JScript.NET编写，可以把JScript.NET当作一种编译语言来运行，而不是解释性的语言，也可以编写强类型化的JScript.NET代码。有了ASP.NET后，就没有必要在服务器端的Web页面上使用脚本语言了，但VBA仍用作Office文档和Visual Studio宏语言。

(5) COM和COM+

从技术上讲，COM 和 COM+并不是面向.NET的技术，因为基于它们的组件不能编译为IL(但如果原来的COM组件是用C++编写的，使用托管C++，在某种程度上可以这么做)。但是，COM+仍然是一个重要的工具，因为其特性没有在.NET中完全实现。另外，COM组件仍可以使用——.NET组合了COM的互操作性，从而使托管代码可以调用COM组件，COM组件也可以调用托管代码(见第33章)。在一般情况下，把新组件编写为.NET组件，其多数目的是比较方便，因为这样可以利用.NET基类和托管代码的其他优点。

4. 应用程序域

应用程序域是.NET中的一个重要技术改进，它用于减少运行应用程序的系统开销，这些应用程序需要与其他程序分离开来，但同时还需要彼此通信。典型的例子是Web服务器应用程序，它需要同时响应许多浏览器请求。因此，要有许多组件实例同时响应这些同时运行的请求。

在.NET没有开发出来前，可以让这些实例共享同一个进程，但此时一个运行的实例就有可能导致整个网站的崩溃；也可以把这些实例孤立在不同的进程中，但这样做会增加相关性能的系统开销。

到现在为止，孤立代码的惟一方式是通过进程来实现的。在运行一个新的应用程序时，它会在一个进程环境内运行。Windows通过地址空间把进程分隔开来。这样，每个进程有4GB的虚拟内存来存储其数据和可执行代码(4GB对应于32位系统，64位系统要用更多的内存)。Windows利用额外的间接方式把这些虚拟内存映射到物理内存或磁盘空间的一个特殊区域中，每个进程都会有不同的映射，虚拟地址空间块映射的物理内存之间不能有重叠，这种情况如图1-2所示。

图  1-2

在一般情况下，任何进程都只能通过指定虚拟内存中的一个地址来访问内存——即进程不能直接访问物理内存，因此一个进程不可能访问分配给另一个进程的内存。这样就可以确保任何执行出错的代码不会损害其地址空间以外的数据(注意在Windows 95/98上，这些保护措施不像在Windows NT/2000/XP/2003上那样强大，所以理论上存在应用程序因写入不对应的内存而导致Windows崩溃的可能性)。

进程不仅是运行代码的实例相互隔离的一种方式，在Windows NT/2000/XP/2003系统上，它们还可以构成分配了安全权限和许可的单元。每个进程都有自己的安全标识，明确地表示Windows允许该进程可以执行的操作。

进程对确保安全有很大的帮助，而它们的一大缺点是性能。许多进程常常在一起工作，因此需要相互通信。一个常见的例子是进程调用一个COM组件，而该COM组件是可执行的，因此需要在它自己的进程上运行。在COM中使用代理时也会发生类似的情况。因为进程不能共享任何内存，所以必须使用一个复杂的编组过程在进程之间复制数据。这对性能有非常大的影响。如果需要使组件一起工作，但不希望性能有损失，惟一的方法是使用基于DLL的组件，让所有的组件在同一个地址空间中运行—— 其风险是执行出错的组件会影响其他组件。

应用程序域是分离组件的一种方式，它不会导致因在进程之间传送数据而产生的性能问题。其方法是把任何一个进程分解到多个应用程序域中，每个应用程序域大致对应一个应用程序，执行的每个线程都运行在一个具体的应用程序域中，如图1-3所示。

图  1-3

如果不同的可执行文件都运行在同一个进程空间中，显然它们就能轻松地共享数据，因为理论上它们可以直接访问彼此的数据。虽然在理论上这是可以实现的，但是CLR会检查每个正在运行的应用程序的代码，以确保这些代码不偏离它自己的数据区域，保证不发生直接访问其他进程的数据的情况。这初看起来是不可能的，如何告诉程序要做什么工作，而又不真正运    行它？

实际上，这么做通常是可能的，因为中间语言拥有强大的类型安全功能。在大多数情况下，除非代码明确使用不安全的特性，例如指针，否则它使用的数据类型可以确保内存不会被错误地访问。例如，.NET数组类型执行边界检查，以禁止执行超出边界的数组操作。如果运行的应用程序的确需要与运行在不同应用程序域中的其他应用程序通信或共享数据，就必须调用.NET的远程服务。

被验证不能访问超出其应用程序域的数据(而不是通过明确的远程机制)的代码就是内存类型安全的代码，这种代码与运行在同一个进程中但应用程序域不同的类型安全代码一起运行是安全的。

1.3.4  通过异常方法处理错误

.NET Framework可以根据异常使用相同的机制处理错误情况，这与Java和C++是一样的。C++开发人员应注意到，由于IL有非常强大的类型系统，所以在IL中以C++的方式使用异常不会带来相关的性能问题。另外，.NET和C#也支持finally块，这是许多C++开发人员长久以来的愿望。

第12章会详细讨论异常。简要地说，代码的某些领域被看作是异常处理程序例程，每个例程都能处理某种特殊的错误情况(例如，找不到文件，或拒绝执行某些操作的许可)。这些条件可以定义得很宽或很窄。异常结构确保在发生错误情况时，执行进程立即跳到异常处理程序例程上，处理错误情况。

异常处理的结构还提供了一种方便的方式，当对象包含错误情况的准确信息时，该对象就可以传送给错误处理例程。这个对象包括给用户提供的相应信息和在代码的什么地方检测到错误的确切信息。

大多数异常处理结构，包括异常发生时的程序流控制，都是由高级语言处理的，例如C#、Visual Basic 2005和C++，任何中间语言命令都不支持它。例如，C#使用try{}、catch{}和 finally{}代码块来处理它，详见第12章。

.NET提供了一种基础结构，让面向.NET的编译器支持异常处理。特别是它提供了一组.NET类来表示异常，语言的互操作性则允许错误处理代码处理被抛出的异常对象，无论错误处理代码使用什么语言编写，都是这样。语言的无关性没有体现在C++和Java的异常处理中，但在COM的错误处理机制中有一定限度的体现。COM的错误处理机制包括从方法中返回错误代码以及传递错误对象。在不同的语言中，异常的处理是一致的，这是多语言开发的重要一环。

1.3.5  特性的使用

特性(attribute)是使用C++编写COM组件的开发人员很熟悉的一个功能(使用Microsoft的COM接口定义语言(Interface Definition Language，IDL))。特性最初是为了在程序中提供与某些项相关的额外信息，以供编译器使用。

.NET支持特性，因此现在C++、C#和Visual Basic 2005也支持特性。但在.NET中，对特性的革新是建立了一个机制，通过该机制可以在源代码中定义自己的特性。这些用户定义的特性将和对应数据类型或方法的元数据放在一起，这对于文档说明书十分有用，它们和反射技术一起使用，以根据特性执行编程任务。另外，与.NET的语言无关性的基本原理一样，特性也可以在一种语言的源代码中定义，而被用另一种语言编写的代码读取。

本书的第11章详细介绍了特性.

 

1.4  程序集

程序集(assembly)是包含编译好的、面向.NET Framework的代码的逻辑单元。本章不详细论述程序集，而在第15章中论述，下面概述其中的要点。

程序集是完全自我描述性的，也是一个逻辑单元而不是物理单元，它可以存储在多个文件中(动态程序集的确存储在内存中，而不是存储在文件中)。如果一个程序集存储在多个文件中，其中就会有一个包含入口点的主文件，该文件描述了程序集中的其他文件。

注意可执行代码和库代码使用相同的程序集结构。惟一的区别是可执行的程序集包含一个主程序入口点，而库程序集则不包含。

程序集的一个重要特性是它们包含的元数据描述了对应代码中定义的类型和方法。程序集也包含描述程序集本身的元数据，这种程序集元数据包含在一个称为程序集清单的区域中，可以检查程序集的版本及其完整性。

注意：

ildasm是一个基于Windows的实用程序，可以用于检查程序集的内容，包括程序集清单和元数据。第15章将介绍ildasm。

程序集包含程序的元数据，表示调用给定程序集中的代码的应用程序或其他程序集不需要指定注册表或其他数据源，以便确定如何使用该程序集。这与以前的COM有很大的不同，以前，组件的GUID和接口必须从注册表中获取，在某些情况下，方法和属性的详细信息也需要从类型库中读取。

把数据分散在3个以上的不同位置上，可能会出现信息不同步的情况，从而妨碍其他软件成功地使用该组件。有了程序集后，就不会发生这种情况，因为所有的元数据都与程序的可执行指令存储在一起。注意，即使程序集存储在几个文件中，数据也不会出现不同步的问题。这是因为包含程序集入口的文件也存储了其他文件的细节、散列和内容，如果一个文件被替换，或者被塞满，系统肯定会检测出来，并拒绝加载程序集。

程序集有两种类型：共享程序集和私有程序集。

1.4.1  私有程序集

私有程序集是最简单的一种程序集类型。私有程序集一般附带在某些软件上，且只能用于该软件中。附带私有程序集的常见情况是，以可执行文件或许多库的方式提供应用程序，这些库包含的代码只能用于该应用程序。

系统可以保证私有程序集不被其他软件使用，因为应用程序只能加载位于主执行文件所在文件夹或其子文件夹中的程序集。

用户一般会希望把商用软件安装在它自己的目录下，这样软件包没有覆盖、修改或加载另一个软件包的私有程序集的风险。私有程序集只能用于自己的软件包，这样，用户对什么软件使用它们就有了更多的控制。因此，不需要采取安全措施，因为这没有其他商用软件用某个新版本的程序集覆盖原来的私有程序集的风险(但软件是专门执行怀有恶意的损害性操作的情况除外)。名称也不会有冲突。如果私有程序集中的类正巧与另一个人的私有程序集中的类同名，是不会有问题的，因为给定的应用程序只能使用私有程序集的名称。

因为私有程序集完全是自含式的，所以安装它的过程就很简单。只需把相应的文件放在文件系统的对应文件夹中即可(不需要注册表项)，这个过程称为“0影响(xcopy)安装”。

1.4.2  共享程序集

共享程序集是其他应用程序可以使用的公共库。因为其他软件可以访问共享程序集，所以需要采取一定的保护措施来防止以下风险：

●       名称冲突，另一个公司的共享程序集执行的类型与自己的共享程序集中的类型同名。因为客户机代码理论上可以同时访问这些程序集，所以这是一个严重的问题。

●       程序集被同一个程序集的不同版本覆盖——新版本与某些已有的客户机代码不兼容。

这些问题的解决方法是把共享程序集放在文件系统的一个特定的子目录树中，称为全局程序集高速缓存(GAC)。与私有程序集不同，不能简单地把共享程序集复制到对应的文件夹中，而需要专门安装到高速缓存中，这个过程可以用许多.NET工具来完成，其中包含对程序集的检查、在程序集高速缓存中设置一个小的文件夹层次结构，以确保程序集的完整性。

为了避免名称冲突，共享程序集应根据私有密钥加密法指定一个名称(私有程序集只需要指定与其主文件名相同的名称即可)。该名称称为强名(strong name)，并保证其惟一性，它必须由要引用共享程序集的应用程序来引用。

与覆盖程序集相关的问题，可以通过在程序集清单中指定版本信息来解决，也可以通过同时安装来解决。

1.4.3  反射

因为程序集存储了元数据，包括在程序集中定义的所有类型和这些类型的成员的细节，所以可以编程访问这些元数据。这个技术称为反射，第11章详细介绍了它们。该技术很有趣，因为它表示托管代码实际上可以检查其他托管代码，甚至检查它自己，以确定该代码的信息。它们常常用于获取特性的详细信息，也可以把反射用于其他目的，例如作为实例化类或调用方法的一种间接方式，如果把方法上的类名指定为字符串，就可以选择类来实例化方法，以便在运行时调用，而不是在编译时调用，例如根据用户的输入来调用(动态绑定)。

1.5  .NET Framework类

至少从开发人员的角度来看，编写托管代码的最大好处是可以使用.NET基类库。

.NET基类是一个内容丰富的托管代码类集合，它可以完成以前要通过Windows API来完成的绝大多数任务。这些类派生自与中间语言相同的对象模型，也基于单一继承性。无论.NET基类是否合适，都可以实例化对象，也可以从它们派生自己的类。

.NET基类的一个优点是它们非常直观和易用。例如，要启动一个线程，可以调用Thread类的Start()方法。要禁用TextBox，应把TextBox对象的Enabled属性设置为false。Visual Basic和Java开发人员非常熟悉这种方式。它们的库都很容易使用，但对于C++开发人员来说这是极大的解脱，因为他们多年来一直在使用诸如GetDIBits()、RegisterWndClassEx()和IsEqualIID()这样的API函数，以及需要传递Windows句柄的函数。

另一方面，C++开发人员总是很容易访问整个Windows API，而Visual Basic 6和Java开发人员只能访问其语言所能访问的基本操作系统功能。.NET基类的新增内容就是把Visual Basic和Java库的易用性和Windows API函数的丰富功能结合起来。但Windows仍有许多功能不能通过基类来使用，而需要调用API函数。但一般情况下，这只限于比较复杂的特性。在日常的使用中，会发现基类非常丰富。如果需要调用API函数，.NET提供了所谓的“平台调用”，来确保对数据类型进行正确的转换，这样无论是使用C#、C++或Visual Basic 2005进行编码，该任务都不会比直接从已有的C++代码中调用函数更困难。

注意：

WinCV是一个基于Windows的实用程序，可以用于浏览基类库中的类、结构、接口和枚举。本书将在第14章介绍WinCV。

第3章主要介绍基类。完成了C#语言语法的概述后，本书的其余内容将主要说明如何使用.NET基类库中的各种类，即各种基类是如何工作的。.NET基类包括：

●       IL提供的核心功能，例如，通用类型系统中的基本数据类型，详见第3章。

●       Windows GUI支持和控件(第23章)

●       Web窗体(ASP.NET，第26~27章)

●       数据访问(ADO.NET，第19~21章)

●       目录访问(第22章)

●       文件系统和注册表访问(第34章)

●       网络和Web浏览(第35章)

●       .NET特性和反射(第11章)

●       访问Windows操作系统的各个方面(例如环境变量等，第16章)

●       COM互操作性(第30和33章)

附带说一下，根据Microsoft源文件，大部分.NET基类实际上都是用C#编写的！

1.6  命名空间

命名空间是.NET避免类名冲突的一种方式。例如，命名空间可以避免下述情况：定义一个类来表示一个顾客，称此类为Customer，同时其他人也在做相同的事(这有一个类似的场景——顾客有相当多的业务)。

命名空间不过是数据类型的一种组合方式，但命名空间中所有数据类型的名称都会自动加上该命名空间的名字作为其前缀。命名空间还可以相互嵌套。例如，大多数用于一般目的的.NET基类位于命名空间System中，基类Array在这个命名空间中，所以其全名是System.Array。

.NET需要在命名空间中定义所有的类型，例如，可以把Customer类放在命名空间YourCompanyName中，则这个类的全名就是YourCompanyName.Customer。

注意：

如果没有显式提供命名空间，类型就添加到一个没有名称的全局命名空间中。

Microsoft建议在大多数情况下，都至少要提供两个嵌套的命名空间名，第一个是公司名，第二个是技术名称或软件包的名称，而类是其中的一个成员，例如YourCompanyName
.Sales Services.Customer。在大多数情况下，这么做可以保证类的名称不会与其他组织编写的类名冲突。

第2章将详细介绍命名空间。