Namespaces can help you organize your business .Net source code, but do this, you must have a reliable plan.
By Jonathan Goodyear, MCSD, MCP, CLS
Remember how difficult is the source code for enterprise organization in COM? Typically, you can only use two levels when named: Project Names and class names. Your ProgID is usually displayed in the following form:
XYZCompanyAccounting.Payroll
Obviously, this method is not ideal. If you can divide the namespace identifier more detailed. For example, in .NET, ProgID can be represented:
Xyzcompany.accounting.payroll
In this example, the difference is not big, but when you define more items, they will be obvious.
In fact, .NET Framework allows you to create deeper nesting namespaces, which make programming work more smoothly (or worse). To use deep nested namespaces, we need to make our plan carefully and require the cooperation of each developing group. This article provides some useful recommendations that describe how to organize source code in the form of namespace, and how to organize business .NET source code in the Visual SourceSafe (VSS) project.
Build your namespace as a starting point, you should start with the company identifier for a source code unit, which is useful. For example, in the previous example, I started with "xyzcompany". The next part of the namespace depends on the scope of the code. If your code is a specific project containing business logic, the next part of the namespace should be the name of your project ("Accounting" in the example). Next is a subdivision of your project ("Payroll" in the example). Therefore, your naming space for your specific project should be:
Xyzcompany.accounting.payroll
Then you can customize classes in the XYZCompany.accounting.Payroll namespace to customize classes. By dividing business logical namespaces on a finer, you can divide the code into a more specific project unit in VSS (I will talk more in more detail later).
The ASP.NET Web project and the Web Services project are special examples of specific project namespaces. For ASP.NET Web projects, a good naming standard is CompanyName.ProjectName.Website. Similarly, a good naming standard for the Web Services project is CompanyName.ProjectName.WebServices.
Based on this grammat, an account website for xyzcompany and the namespace of Web Services will be:
XYZCompany.accounting.Website
XYZCompany.accounting.Webservices
The namespace scheme you use can be changed depending on the purpose of the source code. If you plan to share the code cross your business, you don't put the name of the project in the namespace. I also recommend that you don't create your own naming standard. Alternatively, you should follow Microsoft's standards that have been established for .NET Framework. For example, if XYZComPany's developers want to build a business class library to encapsulate data to SQL Server, they should use the following namespace:
XYZCompany.Data.sqlclient
This namespace simulates the system.data.sqlclClient namespace structure in the .NET Framework. Similarly, if Xyzcompany's developer wants to build a class library to encapsulate their custom event logging, then the following namespace will be suitable: xyzcompany.Diagnostics
Creating a unique class name in your namespace is always very good. In this way, when it is necessary for your code to use the .NET Framework namespace and a specific business namespace, there will be no phenomenon of conflict. For example, you should name the custom event log class EventLogger or XYZEVENTLOG instead of EventLog. I prefer the recommendations mentioned earlier because the company name will be 啰 只 in a full-form (Fully-Qualified) class name.
For several reasons, it is important to build your namespace in this format. First, by establishing a root namespace in the form of a company name, we avoid the possible namespace conflicts when purchasing third-party products. Second, by using the same namespace structure as .NET Framework, you can make developers to provide support for classes that provide support for their needs in the underground architecture. Microsoft's cataloging systems may not be perfect, but the developers have nothing to learn from another corporate catalog system. Third, by building a namespace hierarchy for the enterprise, you can easily use a file generation tool (such as ndoc) to compile a separate MSDN form for the entire class library.
Building your project After building a naming space format, we can consider how to build a project in VSS. I recommend using two project nodes in the top of your VSS tree directory structure:
XYZ Enterprise .NET Class Library
XYZ Project .NET Class Library
figure 1.
Name your project node
These two project nodes allow you to create two separate files (one for specific project code, another for corporate code). Under each top node, create a project node in the form of the company name (XYZCompany in this example). This is your root name space. As for other parts of the VSS project tree directory structure, we can copy the namespace structure you have created, with the folder to replace the dots in the namespace (.), Which is similar to the display form of each level in Java. : Displayed in the code in a circle, display in the ClassPath system environment variable (see
figure 1). Remember, we always need to name your project file with a full form, complete namespace name.
Remove naming standards, I suggest you follow some of the class suffixes that Microsoft has established. For example, attribute classes should be ended with words "Attribute", and the exception class should end with "Exception". That is to say, when you decide to name the class named, you must first determine which type of class it belongs, and view the .NET Framework class library to see if there is a naming standard. If so, follow this naming standard.
The namespace structure I have told is just to help you organize the company's .NET source code. For most companies, .NET is still a new technology, so it is time to use an organized catalog system. Through this article, we will realize the importance of establishing a standard naming structure for your namespace. Otherwise, your .NET code will be a confusing, deep nesting Progid code base, you will be very hard.
About the Author:
Jonathan Goodyear is
Aspsoft (www.aspsoft.com) president, this is an Internet consultation company located in Orlando, Fla. He is a bit MCSD, which is the author of the book of Debugging asp.net (New Riders), you can find it at www.debuggingasp.net. You can pass
Jon@aspsoft.com Contact him or through him
Angrycoder Ezine on www.angrycoder.com That is.
