make. NET namespaces conform to standards

Namespaces can help you organize your business. NET source code, but to do this, there must be a reliable plan. by Jonathan Goodyear, MCSD, MCP, CLS

Remember how hard it is to organize source code for an enterprise in COM? Typically, you can use only two levels when naming: project name and class name. Your ProgID is usually shown in the following form: Xyzcompanyaccounting.payroll. Obviously, this method is not ideal. It would be better if you could divide the namespace identifiers more carefully. For example, in. NET, ProgID can be expressed as: XYZCompany.Accounting.Payroll. In this case, the difference is not very large, but when you define more levels of the project, their differences will be very obvious.

In fact, the. NET framework allows you to create deeper nested namespaces that make programming work smoother (or worse). Using deep nesting namespaces requires that we plan more carefully and require the cooperation of the enterprise development teams. This article provides useful advice on how to organize your source code in the form of namespaces and how to organize your enterprise in a visual SourceSafe (VSS) project. NET source code.

Build Your own namespaces

As a starting point, it is useful that each namespace you allocate for a source unit should begin with a company identifier. For example, in the previous example, I started with "Xyzcompany". The next part of the namespace depends on the scope of the code's purpose. If your code is a specific project that contains business logic, then the next part of the namespace should be the name of your project ("Accounting" in the example). The next step is to subdivide your project ("Payroll" in the example). Therefore, the namespace of your particular project should be: XYZCompany.Accounting.Payroll

You can then customize the class for more specific tasks at hand in the XYZCompany.Accounting.Payroll namespace. By dividing the business logic namespace on a more granular basis, you can split the code into more specific project units in VSS (which I'll cover in more detail later).

asp.net Web projects and Web services projects are a special example of a specific project namespace. A good naming standard for asp.net Web projects is CompanyName.ProjectName.Website. Similarly, a good naming standard for WEB services projects is CompanyName.ProjectName.WebServices.

Based on this syntax, the namespace for Xyzcompany's accounts Web site and Web services will be: XYZCompany.Accounting.Website

XYZCompany.Accounting.WebService

The namespace scheme you use can be changed according to the scope of the source code. If you plan to share your code across the enterprise, do not place the name of the project in the namespace. I also recommend that you do not create your own naming standards. Instead, you should follow the standards that Microsoft has established for the. NET Framework. For example, if Xyzcompany developers want to build an enterprise class library to encapsulate data access into SQL Server, they should use the following namespaces: XYZCompany.Data.SqlClient

This namespace simulates the System.Data.SqlClient named space structure in the. NET framework. Similarly, if a xyzcompany developer wants to build a class library to encapsulate their custom event log, the following namespaces are appropriate: Xyzcompany.diagnostics

It's always nice to create a unique class name in your namespace. In this way, there is no class name conflict when it is necessary for your code to use both the. NET framework namespace and the namespace of a particular enterprise. For example, you should name your custom event log class EventLogger or Xyzeventlog instead of EventLog. I prefer to use the advice I mentioned earlier, because it would be very fully-qualified to list the company names more than once in a fully-formal class name.

For several reasons, it is important to build your namespace in this format. First, by creating a root namespace in the form of a company name, we avoid the possibility of a namespace conflict when we purchase a Third-party product later. Second, by adopting the same named space structure as the. NET framework, you can make it easier for developers to find classes in the enterprise's underlying architecture that provide support for the functionality they need. Microsoft's catalog system may not be perfect, but it doesn't make sense for developers to learn another cataloging system that is specific to your business. Third, by building the namespace hierarchy for the enterprise, you can easily compile a separate MSDN-style file for the entire class library with a file generation tool such as NDoc.

Build your project

Once we have built the namespace format, we can consider how to build the project in VSS. I recommend that you use two project nodes in the top level of your VSS tree structure: XYZ Enterprise. NET Class Library

XYZ Project. NET Class Library

These two project nodes allow you to create two separate files (one for specific project code and another for enterprise code). Under each top-level node, create a project node in the form of a company name (Xyzcompany in this example). This is your root namespace. As for the other parts of the tree directory structure of the VSS project, we can copy the named space structures that you have created, replacing the dots (.) In the namespace with a folder, which is similar to the display of classes at various levels in Java: In code, in dots,

The CLASSPATH system environment variables are displayed in folders (see Figure 1). Remember, we always have to name your project file with a fully-formal, full namespace name.

Referring to naming standards, I recommend that you follow some of the class name suffixes that Microsoft has already established. For example, attribute classes should all end with the word "attribute," and the exception class should end with "Exception". This means that when you decide to name the class you are building, you first determine what type of class it belongs to, and look at the. NET Framework class Library to see if there are any naming standards. If so, follow the naming standard.

I'm talking about the namespace space just to help you organize your business. NET source code. For most companies,. NET is still a very new technology, so it is time to use a well organized cataloging system. With this article, we are aware of the importance of establishing a standard naming structure for your namespaces. Otherwise, your. NET code will be a messy, deeply nested ProgID code base, and you'll have a lot of difficulty in using it.