《设计模式：基于C#的工程化实现及扩展》学习笔记 02 准备篇 -- Namespace(命名空间)

1.2.1 Namespace(命名空间)

1.2.1.1 尴尬的现实状况

是否有很好的命名空间规划是工程化代码与非工程化代码一个很明显的区别。

之前我呆过4家公司，对于命令空间基本上就是<Company>.<Layer>，在每个Layer之下就什么没有细分的命名空间了。这样的弊端是没有一个有效的树形结构，找相应的代码时候会发现每个Layer下都存在大量的文件，导致在找代码的时候是非常痛苦的。

在小系统的时候都会感觉到找代码的痛苦，更不用说对于大型的组织而言，如果涉及的产品线、项目、公共平台很多，如何通过命令空间把所有的代码资源有效的组织起来，恐怕是实施项目前要考虑的主要问题。作为一个树形体系，最好有组织及统一的分类标准，目的很明确-用的时候能很容易找到。

想做到这点不容易,原因如下：

习惯中难以改变的缩写命名：比如说CAD很容易在声明的时候被命名为.***CAD,但事实上Design Guideline(设计方针 备注1)建议的是Cad.这也使得使用者和定义者之间就存在一些小小的错位。建议：如果想避免这样的问题，那么对于公司来说就需要定义设计规范，当然对于一些还未在公司中就职的学习者来说遵循一些行业默认的标准必然是首先需要做到的（可以参考备注1）。

不统一的命名：涉及加密的库，可能A被定义为Encrypt，B被定义为Crypto(加密)或者Cryptography(密码学)，来自匈牙利命名法的“遗毒”也尝尝成为新旧开发人员统一命名的障碍，而且会直接影响到命名空间的定义。

建议：同上一条。

组织或你上司的认同：技术总监不认为命名规范是他需要关心的事情。下面的架构师更关心的是结构，再下面的项目经理关注的是资源调度和进度，具体的实施人员恐怕没有多少机会规定其他同事该怎么命名，那么谁来关心命名空间呢？

　　其实上面说的情况很平凡，在我的经历中，经常会碰到的就是：我的上司或者我的上上司直接就丢给我一个项目名，下面的就让我自己去搞，我还需要去了解这个项目上和哪个硬件工程师合作、用什么硬件、客户是谁、工程部负责人是谁、需求是怎么样的。整个项目基本就没人负责了，全部都要自己搞定，很多时候项目时间紧迫先拿出程序再说吧，这样也导致了自己也没时间去考虑这些问题，就“随心而动”了，最后等需要维护的时候自己都需要找半天。

　　建议：就算没人来管理这些东西了，那自己也要先把这些东西订出来，而且不要设定这些代码只会在这个项目中用，很可能在另外一个项目中也会用到，如何组织那就要运用我们的智慧了。

1.2.1.2 指导方针

谈指导方针之前，我觉得应该首先说明一些程序集和命名空间的概念：

程序集和DLL是一个部署单元，同时还代表托管代码程序的身份。虽然程序集可以分布在一个或多个文件中，但一般来说一个程序集仅与一个DLL相对应。相对来说程序集在概念上来说是对应物理上的分布。

命名空间与DLL和程序集是不同的概念，命名空间对开发人员来说是一组逻辑实体。所以名字空间的组织方式与DLL不同，在一个DLL中可以包含多个名字空间。

由于命名空间的组织方式与DLL不同，命名空间不一定和DLL命名方式相同，虽然我们在VS编译环境下创建项目时命名空间和DLL是同名的，但是因为在逻辑概念上的不同，我们也应该单独设计。

基于概念其实我们应该知道CLR实际上并不强求命名空间和程序集的文件名之间要有任何联系，但是开发人员经常会搞糊涂，例如：虽然System.IO.FileStream在MSCorlib.dll中，但是System.IO.FileSystemWatcher却在System.dll中，我们可以看到，一个命名空间中的类型可以分部在多个文件中。另外请注意，.NET框架中根本没有System.IO.dll这个文件。

　　那么我们在设计命名空间的时候应该遵循什么样的指导方针呢？

　　要确定命名空间设计规范之前我们要先了解程序集的命名规范：

要为程序集和DLL选择提示性的名字，比如System.Data,这样很容易就知道它的大致功能。程序集和DLL的名字不一定要和名字空间相对应，但在给程序集命名时遵循命名空间的名字也是合情合理的。

考虑按照下面的模式给DLL命名：

　　　　<Company>.<Component>.dll

　　　　其中<Component>包含一个或者多个以点号分隔的字句，例如：

　　　　Microsoft.VisualBasic.dll

　　　　Microsoft.VisualBasic.Vsa.dll

　　　　Fabrikam.Security.dll

　　　　Litware.Controls.dll

经过之上我们了解了程序集名称设计规范之后，我们就可以去学习命名空间的设计规范。与其他的命名规范一样，为命名空间命名的目标是清晰的，这样对使用框架的开发人员来说，他们就能立刻知道一个命名空间大概有些什么，下面的模板给出了命名空间命名的一般规则：

　　<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

　　下面是一些例子：

　　Microsoft.VisualStudio

　　Microsoft.VisualStudio.Design

　　Fabrikam.Math

　　那么我们的指导方针就是：

要用公司名称作为命名空间的签字，这样就可以避免与另外一家公司使用相同的名字，例如，微软提供的Microsoft Office自动化API应该放在Miscrosoft.Office命名空间中。我在写我自己的程序的时候我喜欢用我的名字缩写加生日作为前缀:dxq0911.UI.Wpf。

要用稳定的、与版本无关的产品名称作为命名空间的第二层。当然产品名称我们还是起个英文的吧，虽然可能只有我们自己看。

不要根据公司的组织架构来决定命名空间的层次结构，因为公司内部组织的名称一般来说不会持续太长的时间。

要使用PascalCasing大小写风格，并用点号来分割命名空间中的个部分（例如Microsoft.office.PowerPoint）。如果商标使用了非传统的大小写风格，那么即使该风格与常规的大小写风格相背，也还是应该遵循商标的大小写风格。

考虑在适当的时候在命名空间中使用复数形式。

　　 例如，要用System.Collections,而不要用System.Collection。但是，商标名称和首字母缩写例外。例如，要用System.IO,而不要用System.IOs。

不要用相同的名字来命名命名空间与位于该名字空间中的类型。

　　 例如，不要先将名字空间命名为Debug，然后又在该名字空间中提供一个名为Debug的类。许多编译器都要求用户在使用这样的类型时要加上完整的限定符。在VS中这样会报错的，提示不知道引用的是那个或者 　　提示未正确引用。

1.2.1.3 企业.NET类型系统的命名空间规划示例

根据之前Design Guideline的规范进行一个总体命名空间的规划，情况 如下：

C#（一级命名空间）

Namespace MarvellousWorks.Application

　　Namespace MarvellousWorks.Foundation

　　Namespace MarvellousWorks.Framework

　　Namespace MarvellousWorks.Utility

　　Namespace MarvellousWorks.Training

Application：代表项目或产品。

Foundation：代表公共库，类似Enterprise Library之类的公共基础库、基于企业设备和操作系统平台的通用的图形处理引擎等，但都是纯粹的Class Library，没有UI元素。

Framework：组织通用的架构，基于Foundation之上；面向某个开发领域扩充的Class Library和控件，其本身不能独立运行，但完全可以继承在具体的项目或产品中，比如通用的授权框架、完全Ajax化的前 后端组件、报表和打印中间件。

Utility：企业内部各种工具，比如现场故障排查工具、Dump和日志分析工具。

Training：完全面向培训用途，是对企业自身Application、Foundation、Framework（甚至Utility）使用的示例。

　　几个一级命名空间的布局如图1-1所示。



图1-1 一个建议的一级命名空间布局和调用关系

　　备注1：《.NET设计规范》人民邮电出版社 ISBN 7-115-14929-1/TP.5508