email article printer friendly more resources

Standardize Your .NET Namespaces
Namespaces can help you organize your company's .NET source code, but only if you have a solid plan.
by Jonathan Goodyear, MCSD, MCP, CLS

April 2003 Issue

Remember how difficult it was in the COM world to organize the source code for your enterprise? You typically only had two naming levels to work with: project name and class name. All too often your ProgIDs ended up looking like this:

XYZCompanyAccounting.Payroll

Obviously, this is not ideal. It would be better if you could separate the namespace identifier more. For example, ProgID might be represented in .NET this way:

XYZCompany.Accounting.Payroll

The difference is subtle in this case, but the difference becomes more apparent as you define deeper project hierarchies.

The fact that the .NET Framework offers you the ability to create more deeply nested namespaces can make things much better for you—or much worse. Reaping the benefits of deeply nested namespaces requires careful planning and consideration, as well as coordination among the various development groups in your organization. This article offers you some helpful suggestions to organize your enterprise .NET source code, both in namespace form and in Visual SourceSafe (VSS) projects.

Structure Your Namespaces
As a helpful starting point, each namespace that you assign to a unit of source code should begin with a company identifier. For instance, my previous example begins with "XYZCompany." The next section of your namespace depends on the intended scope for the code. If the code is business logic–specific to a project, then the next section of your namespace should be the name of your project ("Accounting," in this case). Following that is the specific subsection of your project ("Payroll," in this case). This means your project-specific namespace should be:

XYZCompany.Accounting.Payroll

You can then tailor the classes within the XYZCompany.Accounting.Payroll namespace to the more specific tasks at hand. By segmenting business logic namespaces on a more granular basis, you can divide your code into more specific project units in VSS (more on that later).

ASP.NET Web projects and Web services projects are special cases of project-specific namespaces. A good standard to follow for ASP.NET Web projects is CompanyName.ProjectName.Website. Likewise, a good standard namespace format for a Web services project is CompanyName.ProjectName.WebServices.