Namespaces - How deep is too deep

Question

We are currently reorganising some of our services projects so their naming is more logical. We have the following structure:

Djp.Services.Type. ServiceName

This seems to make sense as a logical grouping, however what I want to know is, is it acceptable to have further levels under this based on the folders in the project. For example one project is called

Djp.Services.Management.Data

Under this project we have a "POCO" folder and a "Repositories" folder, which means, in principal, objects under these folders will have a namespace 5 levels deep.

Is this depth of namespace something that should avoided, or is it perfectly reasonable?

Answer 1

Any namespace that follows the logic of your application structure is fine - regardless of the length.

Answer 2

It something smells too long, step back and analyze it. If it passed muster, then I agree completely with @Bozho.

Software development is extremely objective and full of exceptions to hard-fast rules. (couldn't resist)

Answer 3

It can be handy to make your folder structure match your namespace structure, but it makes no sense to make a namespace structure match a folder structure.

The types and members of the namespace(s) are the things you are making. That is the output of your craft and the thing you should be concerned about. The files in the folder are a way to help you do so. You may have already structured the folders such that they match a sensible namespace (essentially you "wrote" the namespace structure when you did so), in which case all and good, but you may also have not done so. The namespaces will matter both to the creators of the assembly(s) and the users of it, the folder structure only to the creators.

Ignore depth, ignore folders, look at the spaces created by the names.