Good Namespace Naming Conventions

Question

I am creating a class library for a CRUD business application. The major \"categories\" of business objects (with related data access layer objects) are:

• Maint

Answer 1

After going through this a lot, we try to keep the number of namespaces low (less than a few dozen for a very large project), and the depth of the namespaces short (less than 5 or so). From a consumption standpoint (developers using our codebase), it is an overhead with very little benefit to have to keep track of a large number of namespaces with few classes in them.

We also group like with like, based on usage. If a developer is fairly likely to always use certain classes in conjunction with others, even though (in your example) one may be related to Maintenance and the other not, if they are logically, operationally or procedurally related we put them in the same namespace. The functionality that is separate (for example, maintenance-specific logic) is broken into another namespace using a provider model. Since a developer is less likely to need to modify the provider-contained functionality, that goes in a deeper, separate namespace.