Namespace hierarchy in C#

Question

I have a C# class library shared among several applications. The library is divided into a few smaller components which have dependencies shown in the picture below. Each component is placed in its own namespace to enforce the component boundaries:

Core <- Component A <---- Component B <----- Application
 ^ ^------ Component C <---/
 \--- Component D <--/

Now I am thinking about the namespace hierarchy. So far I have found two different approaches:

1. Nested namespace extends the parent namespace, so that the parent namespace can exist without the child components. Alternatively the nested namespace contains implementation of the interfaces from the parent namespace. I believe this approach is used in standard .NET libraries.

2. Parent namespace acts as a mediator which interconnects nested namespaces to form the whole application/super component (described in this article).

Question: Shall the namespace (and folder) hierarchy reflect the namespace dependencies? What is the preferred way of dealing component/namespace dependencies in large projects?

Answer 1

Namespaces provide context in order to name things. They also provide means to avoid conflicts when two different organizations make the name.

 - CompanyA.File 
 - CompanyB.File

In this case, both use File but one can reference both in your application without conflict.

Usually a hierarchy is made in order to provide a means to classify components. Examples:

 - Company.Core.Http 
 - Company.Core.Error

And then

 - Company.CoolApp.Dto.Product

Here I have a created a hierarchy to define core components as well as a hierarchy for an application as well.

Usually these hierarchy's are made up ahead of time and have some sort of convention to it. There is no right or wrong here.

But usually the first level is your ID, second level Common/Core or Application, and 3rd and beyond would be the hierarchy of components that are developed. This would also depend on how your company is structured as well.

Usually the top layer is what identifies you or your org. Under that it is usually grouped by core or common and then by application. As teams write code, components may be moved if an application component is deemed to be a common or core component.

Usually components that are cross cutting are in common or core. These include error handling, logging, etc.

Application components are specific to the application and are usually defined by the development teams. If an application uses Dto or Model as classes to define entities one might what to develop namespace standards that go across applications or products. For example, all entity classes go under a namespace called Model. Then you have some consistency across applications.

For example:

 - Company.CoolApp.Model.Foo 
 - Company.CrappyApp.Model.Foo
 - Company.CrappyApp.Model.Bar

This allows someone at a high level to determine if:

Company.Core.Model.Foo ...should exist, since they can look across applications and determine if it can be consolidated.

• Mike Robinson: I also find that well-designed, consistent namespaces make the source code much more readable. In Jon's example above ... "what's Foo?" Well, he tells you. Even in cases where they aren't strictly necessary – where the compiler could figure things out on its own – a well-thought-out namespace convention provides clarity. (As well as another chance for the compiler to catch your stupid mistakes, which is always a good thing ...)
• Honza Vojtěch: And would you prefer namespace names MyLibrary.ComponentA and MyLibrary.ComponentB or MyLibrary.ComponentA and MyLibrary.ComponentA.ComponentB to reflect B depends on A?
• Jon Raynor: What happens if you have Component C that only depends on B and not A? The namespaces are organized more along the lines of organization and not dependencies among components. Hope that helps.