Namespace naming conventions in dotnet

I typically use this convention:

CompanyName.ApplicationName.Functionality

e.g.

Acme.EmailService
Acme.EmailService.Dal
Acme.EmailService.BusinessLogic
Acme.EmailService.BusinessLogic.ErrorHandling

but where I currently work, they use:

CompanyName.Functionality.ApplicationName

Acme.EmailService
Acme.Dal.EmailService
Acme.BusinessLogic.EmailService
Acme.BusinessLogic.EmailService.ErrorHandling

The last namespace looks a bit weird to me. It is a subfolder of the businesslogic project so by default the foldername is appended to the namespace.

I have seen plenty of naming convention standards but none seem to mention this issue.

What are the Pros and Cons of each ap开发者_运维问答proach?

Follow the naming guidelines that Microsoft has created:

The name chosen for a namespace should indicate the functionality made available by types in the namespace. For example, the System.Net.Sockets namespace contains types that enable developers to use sockets to communicate over networks.

The general format for a namespace name is as follows:

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

For example, Microsoft.WindowsMobile.DirectX.

Do prefix namespace names with a company name to prevent namespaces from different companies from having the same name and prefix.

http://msdn.microsoft.com/en-us/library/vstudio/ms229026(v=vs.100).aspx

In this case I would argue that BusinessLogic or Dal is just layer abstractions and really do not belong in namespaces. Hence I would not use any of you examples, just

Acme.EmailService

Those extra name spaces just makes it harder to find the proper interface/class. You are using multiple assemblies anyway, right? Your different layers will be separated anyway (with the help of the assemblies).

Ask yourself what the layer namespaces really gives you? How many classes are in each namespace? Under 10? Does it make it harder or easier to work with your code?

Firstly, if I have any library/common code, it goes in a non-customer specific namespace (here, CompanyName is where I work):

CompanyName.DB
CompanyName.Common
CompanyName.Web

etc.

Secondly, if it is customer-specific I use the ClientName.Application.Functionality form. This is because if it is not common (and therefore would be in the aforementioned libraries & namespaces), I believe that the functionality belongs to an Application, not the other way around.

Just my opinion, obviously ;)

EDIT: Clarification, I use ClientName as the Top-level namespace for a particular client. We have multiple projects with some clients, and so you can end up with:

ClientName.Common
ClientName.Application1
ClientName.Application2

etc...

I believe that using the second convention may mess things up if you have too many sub layers. For instance one of our projects contains more than 200 projects and i choose to group namespaces by project, not by functionality because the functionality belongs to application except common (really common) functions.

Think about Framework, we might be using namespaces like System.Ui.Web which contains all ui related sub namespaces instead of our current architecture, System.Web.Ui which groups namespaces by platform / application.

I don't believe that there is a exact truth, i believe that there are habits and it is very hard to convince people to change the conventions.