Namespace organisation concepts for large c# applications
I am actually starting a whole new Project in which I now already have lots of Projects. What I'm questioning is the practice that the majority of people would propably build their namespaces the same way as they build up their Project-hierarchy.
Example:
Inside an n-Tier Application you might have a Presentation Layer which could contain three Modules
- Startup
- Core
- SomeModule
A "normal" Namespace could now look as follows: <CompanySpecific>.Presentation.<ProjectName>.<IndividualStuff>
this looks good right? you could totally organize your Namespaces like that, but consider the following.
Imagine Core and SomeModule would both have Windows and Controls subnamespaces. This would mean that to use all Controls and Windows, you would propably add those using directives:
using <CompanySpecific>.Presentation.Core.Windows;
using <CompanySpecific>.Presentation.Core.Controls;
using <CompanySpecific>.Presentation.SomeModule.Windows;
using <CompanySpecific>.Presentation.SomeModule.Controls;
The deeper your namespaces get, the more you need to include.
Sou you could totally just omit the Project-Part of the Namespace. Which would result in those namespaces beeing Extended by Core and SomeModule:
using <CompanySpecific>.Presentation.Windows;
using <CompanySpecific>.Presentation.Controls;
Which Classes you really can access then is depending to your Project-Dependencies, as before.
Question
You now know which Kind of Question this is leading to. I wan't to state this a bit more precisely.
- Does it make sense to use the Project's Name inside the Namespace?
- Would you Group your namespaces also by Architecture-Tiers? (as I did here with Presentation)
- Are there other criteria which might help building Namespaces?
- Is there any known Best Practice to do this? (not too Flat, neither too Deep)
First of all, the name of the assembly should match the namespace. JetBrains ReSharper will ping you on that and pretty sure FXCop will too.
Microsoft has a long standing recommendation for namespace naming as:
CompanyName.TechnologyName[.Feature][.Design]
- more...
Which is still used to this day. Take this Microsoft Azure example:
Microsoft.Azure.Management.Compute
Does it make sense to use the Project's Name inside the Namespace?
Yes because if you don't it implies that the assembly has company-wide usage which may not be the case. If an assembly is project/technology specific then name it so. The Azure example above would be confusing if it were called "Microsoft.Management.Compute"
Would you Group your namespaces also by Architecture-Tiers?
I'm assuming you mean assemblies as you wouldn't want to mix layer code in the same assembly.
Yes. Say I have a WCF & EF application then I would have something like:
Muppets.ToyShop.Contracts
Muppets.ToyShop.ClientProxies
Muppets.ToyShop.Services
Muppets.ToyShop.ServiceHost
Muppets.ToyShop.WebApp
Muppets.ToyShop.FatClient
Muppets.ToyShop.Datum
Are there other criteria which might help building Namespaces?
Sometimes I like to put all my interfaces into a child Interfaces namespace. Lately I don't as nDepend frowns on this.
Is there any known Best Practice to do this? (not too Flat, neither too Deep)
Tools like nDepend can perform static code analysis and it will recommend you collapse child namespaces into one if all classes refer to each other in one way and are in the same assembly due to coupling reasons. In other words it can recommend abolishment of namespace excessiveness.
nDepend's awesome dependency structure matrix not only shows you what types in an assembly are used elsewhere but is useful in locating those namespaces that arguably should be flattened due to tight cohesion.
