您当前的位置: 首页 » ASP/ASP.NET编程 » 使.NET命名空间符合标准
使.NET命名空间符合标准
论坛链接
命名空间可以帮你组织企业的.NET源代码，但要做到这一点，必须要有可靠的计划。by Jonathan Goodyear, MCSD, MCP, CLS
还记得在COM中为企业组织源代码有多难吗?典型情况下，你在命名时只可以用两个级别(level)：项目名称和类名称。你的ProgID通常是以下面的形式显示的：XYZCompanyAccounting.Payroll。显然，这种方法并不理想。如果可以更细地划分命名空间标识符就更好了。例如，在.NET中，ProgID可以表示成：XYZCompany.Accounting.Payroll。在这个例子中，两者的差别并不大，但当你在定义层次更多的项目时，它们的差别就会很明显了。
实际上，.NET Framework可以让你创建更深层嵌套的命名空间，这种功能会使编程工作更顺利(或更糟)。要运用深层嵌套的命名空间需要我们更仔细地做计划，并需要企业各开发小组的配合。本文提供了一些有用的建议，讲述了如何以命名空间的形式来组织源代码，以及如何在Visual SourceSafe(VSS)项目中组织企业的.NET源代码。
构建你的命名空间
作为出发点，你为一个源代码单元分配的每个命名空间都应该以公司标识符开头，这是很有用的。例如，在前面的例子中，我是以“XYZCompany”开头的。命名空间的下一部分取决于代码的目的范围。如果你的代码是包含商业逻辑的一个特定项目，那么命名空间的下一部分就应该是你的项目的名称(例子中的“Accounting”)。接下来是细分你的项目(例子中的“Payroll”)。因此，你的特定项目的命名空间就应该是：XYZCompany.Accounting.Payroll
然后，你可以在XYZCompany.Accounting.Payroll命名空间中为手头更具体的任务来定制类。通过在更细的基础上划分商业逻辑命名空间，你就可以在VSS中将代码分成更具体的项目单元(我在后面会更详细地对此加以讲述)。
ASP.NET Web项目和Web services项目是特定项目命名空间的特殊的例子。对于ASP.NET Web项目来说，一个很好的命名标准就是CompanyName.ProjectName.Website。同样，Web services项目的一个很好的命名标准就是CompanyName.ProjectName.WebServices。
根据该语法，用于XYZCompany的帐目网站和Web services的命名空间就会是：XYZCompany.Accounting.Website
XYZCompany.Accounting.WebService
你运用的命名空间方案可以根据源代码的目的范围改变。如果你打算让代码跨企业共享，那么在命名空间中就不要放项目的名称。我还建议你不要创建自己的命名标准。作为替代，你应该遵循Microsoft已经为.NET Framework建立的标准。例如，如果XYZCompany的开发人员要构建一个企业类库来将数据访问封装到SQL Server中，那么他们应该用下面的命名空间：XYZCompany.Data.SqlClient
该命名空间模拟了.NET Framework中的System.Data.SqlClient命名空间结构。同样，如果XYZCompany的开发人员要构建一个类库来封装他们自定义的事件日志(event logging)，那么下面的命名空间就会很适合：XYZCompany.Diagnostics
在你的命名空间中创建唯一的类名总是很好的。通过这种方法，当有必要让你的代码同时运用.NET Framework命名空间和特定企业的命名空间时，就不会出现类名冲突的现象。例如，你应该将自定义的事件日志类命名为EventLogger或XYZEventLog，而不是EventLog。我更喜欢用前面提到的建议，因为在一个完全形式的(fully-qualified)类名中不只一次地列出公司名称会很啰唆。
出于几个原因，以这种格式构建你的命名空间是很重要的。首先，通过建立一个公司名形式的根命名空间，我们在以后购买第三方产品时就避免了可能出现的命名空间冲突现象。第二，通过采用与.NET Framework一样的命名空间结构，你就可以让开发人员更容易地在企业底层架构中找到为他们所需要的功能提供了支持的类。Microsoft的类编目系统可能并不完善，但是让开发人员去学习另外一个特定于你的企业的编目系统并没有意义。第三，通过为企业构建命名空间层次，你就可以很容易地用一个文件生成工具(如NDoc)为整个类库编译一个单独的MSDN形式的文件了。
构建你的项目
在构建好命名空间格式后，我们就可以考虑如何在VSS中构建项目了。我建议在你的VSS树状目录结构的顶层中运用两个项目节点：XYZ Enterprise .NET Class Library
XYZ Project .NET Class Library
这两个项目节点可以让你创建两个单独的文件(一个用于特定项目代码，另一个用于企业代码)。在每个顶层节点下，以公司名的形式创建一个项目节点(本例中的XYZCompany)。这就是你的根命名空间。至于VSS项目树状目录结构的其它部分，我们可以复制你已经创建的命名空间结构，用文件夹来替代命名空间中的圆点(.)，这同Java中各层次的类的显示形式是类似的：在代码中以圆点显示、
还记得在COM中为企业组织源代码有多难吗?典型情况下，你在命名时只可以用两个级别(level)：项目名称和类名称。你的ProgID通常是以下面的形式显示的：XYZCompanyAccounting.Payroll。显然，这种方法并不理想。如果可以更细地划分命名空间标识符就更好了。例如，在.NET中，ProgID可以表示成：XYZCompany.Accounting.Payroll。在这个例子中，两者的差别并不大，但当你在定义层次更多的项目时，它们的差别就会很明显了。
实际上，.NET Framework可以让你创建更深层嵌套的命名空间，这种功能会使编程工作更顺利(或更糟)。要运用深层嵌套的命名空间需要我们更仔细地做计划，并需要企业各开发小组的配合。本文提供了一些有用的建议，讲述了如何以命名空间的形式来组织源代码，以及如何在Visual SourceSafe(VSS)项目中组织企业的.NET源代码。
构建你的命名空间
作为出发点，你为一个源代码单元分配的每个命名空间都应该以公司标识符开头，这是很有用的。例如，在前面的例子中，我是以“XYZCompany”开头的。命名空间的下一部分取决于代码的目的范围。如果你的代码是包含商业逻辑的一个特定项目，那么命名空间的下一部分就应该是你的项目的名称(例子中的“Accounting”)。接下来是细分你的项目(例子中的“Payroll”)。因此，你的特定项目的命名空间就应该是：XYZCompany.Accounting.Payroll
然后，你可以在XYZCompany.Accounting.Payroll命名空间中为手头更具体的任务来定制类。通过在更细的基础上划分商业逻辑命名空间，你就可以在VSS中将代码分成更具体的项目单元(我在后面会更详细地对此加以讲述)。
ASP.NET Web项目和Web services项目是特定项目命名空间的特殊的例子。对于ASP.NET Web项目来说，一个很好的命名标准就是CompanyName.ProjectName.Website。同样，Web services项目的一个很好的命名标准就是CompanyName.ProjectName.WebServices。
根据该语法，用于XYZCompany的帐目网站和Web services的命名空间就会是：XYZCompany.Accounting.Website
XYZCompany.Accounting.WebService
你运用的命名空间方案可以根据源代码的目的范围改变。如果你打算让代码跨企业共享，那么在命名空间中就不要放项目的名称。我还建议你不要创建自己的命名标准。作为替代，你应该遵循Microsoft已经为.NET Framework建立的标准。例如，如果XYZCompany的开发人员要构建一个企业类库来将数据访问封装到SQL Server中，那么他们应该用下面的命名空间：XYZCompany.Data.SqlClient
该命名空间模拟了.NET Framework中的System.Data.SqlClient命名空间结构。同样，如果XYZCompany的开发人员要构建一个类库来封装他们自定义的事件日志(event logging)，那么下面的命名空间就会很适合：XYZCompany.Diagnostics
在你的命名空间中创建唯一的类名总是很好的。通过这种方法，当有必要让你的代码同时运用.NET Framework命名空间和特定企业的命名空间时，就不会出现类名冲突的现象。例如，你应该将自定义的事件日志类命名为EventLogger或XYZEventLog，而不是EventLog。我更喜欢用前面提到的建议，因为在一个完全形式的(fully-qualified)类名中不只一次地列出公司名称会很啰唆。
出于几个原因，以这种格式构建你的命名空间是很重要的。首先，通过建立一个公司名形式的根命名空间，我们在以后购买第三方产品时就避免了可能出现的命名空间冲突现象。第二，通过采用与.NET Framework一样的命名空间结构，你就可以让开发人员更容易地在企业底层架构中找到为他们所需要的功能提供了支持的类。Microsoft的类编目系统可能并不完善，但是让开发人员去学习另外一个特定于你的企业的编目系统并没有意义。第三，通过为企业构建命名空间层次，你就可以很容易地用一个文件生成工具(如NDoc)为整个类库编译一个单独的MSDN形式的文件了。
构建你的项目
在构建好命名空间格式后，我们就可以考虑如何在VSS中构建项目了。我建议在你的VSS树状目录结构的顶层中运用两个项目节点：XYZ Enterprise .NET Class Library
XYZ Project .NET Class Library
这两个项目节点可以让你创建两个单独的文件(一个用于特定项目代码，另一个用于企业代码)。在每个顶层节点下，以公司名的形式创建一个项目节点(本例中的XYZCompany)。这就是你的根命名空间。至于VSS项目树状目录结构的其它部分，我们可以复制你已经创建的命名空间结构，用文件夹来替代命名空间中的圆点(.)，这同Java中各层次的类的显示形式是类似的：在代码中以圆点显示、
#2楼发布者：superadmin时间：2009-05-15 11:44:30
在CLASSPATH系统环境变量中用文件夹显示(见图1)。记住，我们总是需要用完全形式的、完整的命名空间名称来命名你的项目文件。
提到命名标准，我建议你遵循Microsoft已经建立的一些类名后缀。例如，属性类都应该是以单词“Attribute”结尾的，异常类都应该以“Exception”结尾。这就是说，你在决定为准备构建的类命名时，先要确定它属于哪种类型的类，并查看.NET Framework类库，看看是否已经有命名标准了。如果有，就遵循该命名标准。
我所讲述的命名空间结构只是为了帮你组织企业的.NET源代码。对于大多数公司来说，.NET还是项很新的技术，所以现在运用一个组织好的编目系统正是时候。通过本文，我们就会意识到为你的命名空间建立一个标准的命名结构的重要性。否则，你的.NET代码就会是个混乱的、深层嵌套的ProgID代码库，你在运用它时，就会很费劲。
提到命名标准，我建议你遵循Microsoft已经建立的一些类名后缀。例如，属性类都应该是以单词“Attribute”结尾的，异常类都应该以“Exception”结尾。这就是说，你在决定为准备构建的类命名时，先要确定它属于哪种类型的类，并查看.NET Framework类库，看看是否已经有命名标准了。如果有，就遵循该命名标准。
我所讲述的命名空间结构只是为了帮你组织企业的.NET源代码。对于大多数公司来说，.NET还是项很新的技术，所以现在运用一个组织好的编目系统正是时候。通过本文，我们就会意识到为你的命名空间建立一个标准的命名结构的重要性。否则，你的.NET代码就会是个混乱的、深层嵌套的ProgID代码库，你在运用它时，就会很费劲。