前言
本篇讲述枚举和名称空间。
01
枚举
首先需要明确枚举的概念：枚举是用户定义的整数类型。使用枚举的目标是，使用一组容易记忆的名称，来使得代码更容易编写和维护。
我们对比枚举的定义和类的定义，会发现它们有像的地方，有不像的地方，这不同之处体现了枚举的特性。我们按下图举例：
- C#中，一般习惯于一个文件定义一个类。而一个项目中可能有大量枚举，一般建议将多个枚举定义在一个文件中。
- 很多书中对于枚举只有一个称谓“枚举”，但是，如上图，到底是OrgType1是枚举，还是Vendor是枚举？实际上准确的说，OrgType1是枚举，Vendor是枚举值，或者叫枚举成员。枚举的枚举成员和类的成员本质上是一样的，都可以通过反射获得成员的定义。枚举值本质是System.Enum，是一个结构（struct）。
- 枚举值可以强制指定，比如OrgType2。不指定时默认从0开始计数，比如OrgType1。OrgType1和OrgType2的枚举值是一样的，都是0和1。而OrgType3的枚举值是100和101。枚举值也就可以强制转换成int
int value = (int)OrgType1.Vendor;
枚举值被设计成简单的整数，也是可以理解的，这使得在语言层面上枚举的实现是简约的，高效的。
- 枚举的一个常用功能是将字符串转换为枚举值
var enumTemp = (OrgType1)Enum.Parse(typeof(OrgType1), “Vendor”);
从语言层面上看，枚举定义的可谓非常完美。因为语言层面上，实际上我们只需要使用枚举值（name）就行了，完全不需要关注枚举值背后的int值。但是，当我们要将枚举值序列化时，就出现问题了。
所谓序列化，也就是将枚举数据存储起来，一个常用的应用场景就是存储到数据库的某个字段中。在序列化时，枚举特别适合表示数据库表的状态列，而存储在数据库中的状态列有两种，一种是字符串状态值，一种是int状态值，也可能两者混合。比如：
我们发现，如果要把上述两种状态值都用枚举表示，前者要使用枚举值的表面量（name）来表示，后者要用int值来表示。比如以上两种定义方式，对应的枚举会定义为：
而它们的序列化和反序列化的方式，也各不相同：
针对不同的枚举定义，需要使用不同的序列化和反序列化方式，会使编程变得繁琐，有没有将两者统一的方法呢？我的做法是，使用特性。
如上图，不管是什么样的枚举定义方式，都使用特性EnumItemValue来描述。进行一定的封装之后，枚举的序列化和反序列化就统一为一种模式了：
bill.Status = EnumChangeBillStatus.Data1.GetEnumItemValue();
实现代码：
02
名称空间
名称空间
名称空间就是namespace定义。特别重要的是，名称空间是一种逻辑组合，而不是物理组合。
类似的，在Visual Studio中，也有类似“名称空间”或者“路径”，分别属于“逻辑组合”或者“物理组合”。
解决方案目录：解决方案目录属于逻辑组合，它并不对应磁盘中的实际目录，而只是解决方案文件中的一个逻辑位置定义。
项目中的目录：项目中的目录对应磁盘上实际的文件夹目录，是一个物理位置。
名称空间可以嵌套，比如下图中，上面的嵌套声明方式和下面的声明方式，效果是等同的。不过我们一般不会用上面这种方式，而用下面的方式：
Using
引入类之前一般需要通过using引入类所在的名称空间，从而方便类的引用。如：
using System;
using MJ = BL.Test.ConsoleTest.CSharp高级编程.枚举;
如上的例子上，还用到了别名MJ。一般在碰到在不同的namespace下有两个同名类时，会使用别名。访问别名下的类，使用别名修饰符 ::
var value1 = (int)MJ.OrgType1.Vendor;
var value2 = (int)MJ::OrgType1.Vendor;
我发现，使用::和.都能访问别名下的类，那为什么C#要特别设计“别名修饰符”呢？暂时不能理解。
下一篇将完成第二章的解读。会讲一些细小的特性和功能：Main方法，控制台，注释，预处理指令，编程规范等。
觉得文章有意义的话，请动动手指，分享给朋友一起来共同学习进步。
欢迎关注本人微信公众号，更及时的关注最新文章（每周三篇原创文章，以及多篇专题文章）：
附文：