Role of Namespaces
As mentioned in Chapter 1, namespaces are used to organize code both within and among assemblies. Basically, your decisions as a VB.NET developer involve determining to which namespace your classes will belong and whether your assemblies will contribute classes to a particular namespace given that namespaces can cross assembly boundaries. At an organizational level, a company should plan its namespace hierarchy and publish it so that developers can integrate their code into it and so that other developers will be able to easily identify and reuse existing code.
Typically, the considerations mentioned here are most appropriate for classes you want to publish in DLLs created in class library projects.
For example, the company I work for, Quilogy, might want to group all its reusable code under the Quilogy namespace. As a result, individual developers must be aware of the naming structure the company has set up and which child namespaces have been used and which are available. Figure 4.1 shows a sample of a namespace hierarchy that Quilogy might use, including some of the classes that might be developed. Note that in Figure 4.1 the namespaces are derived from the lines of business that Quilogy engages in and that only the Education namespace is populated. The Education namespace also consists of both classes (Instructors) and nested namespaces (Enrollment and Schedule).
Figure 4.1. Sample namespace hierarchy. This chart shows a sample namespace configuration for Quilogy. Note that the namespaces and classes can be nested at the same level.
Also keep in mind that namespaces can be nested and that any namespaces or classes defined always exist in the global namespace, which by default is the name of the project. You can change this in the VS.NET IDE by clicking on the project and changing the appropriate project property to a different namespace or to none at all. If you change it to none at all, you would need to place explicit Namespace declarations in your code. This flexibility allows you to decouple the name of the DLL from the namespaces it contains and allows any DLL to contribute members (either nested namespaces or classes) to the namespace.
You can also override the behavior of the global namespace by using the command-line compiler (vbc.exe) rather than compiling in VS.NET. By specifying the \rootnamespace option at the command line, you can dictate that all your classes (types) be placed under the namespace you specify.
For example, the following code snippet shows how the namespace statement is used to create nested namespaces:
Namespace Quilogy Namespace Education Public Class Instructors End Class End Namespace End Namespace
In this case, the Instructors class would be referenced as Quilogy.Education.Instructors.
Because global namespaces are the default, you can also take advantage of this fact to create a naming scheme for your assemblies. By using the global namespace, the highest level namespace that you are exposing in your DLL (in the case of a single-file assembly) will be the name of the DLL. For example, the classes that exist directly under the Quilogy.Education namespace will be placed in the Quilogy.Education.dll because the DLL contains a global namespace equivalent to the name of the DLL. Nested namespaces could then appear within the DLL as well.
In this case, namespaces do have an effect on how assemblies are constructed. In the example in Figure 4.1, the Students and Registration classes would both exist in the same namespace, and so both would exist in an assembly that is created at the boundary of one of the higher-level namespaces (Enrollment, Education, or Quilogy). If followed rigorously, the end result is that if you want to add classes from a new assembly to an existing namespace, you create a new assembly that creates a nested namespace. This technique implies the design rule that you create nested namespaces at assembly boundaries. In other words, you would group classes together in a nested namespace that will be distributed, reused, and secured as a unit.
Finally, remember that namespaces are used to organize code and do not affect the inheritance hierarchy. In other words, a class from one namespace can be used as the base class for a class in a separate namespace. All that is required is that the assembly containing the base class be referenced by the namespace that contains the derived class.