Namespace organization

[Dave Slinn]

Any advice on how to organize my core class library project into
sub-namespaces? What are the general rules of thumb regarding
cross-namespace references? Can I have a class in namespace A have a
function or a property that returns a class from a different namespace?

For example, lets say I have a root namespace called ACME for my class
library project. Under the root namespace are classes such as Individual,
Address, etc. I also have a namespace defined for financial classes, called
ACME.Financial, which contains classes such as Invoice and Transaction.
Under Financial is a subnamespace called Discounts
(ACME.Financial.Discounts). A second namespace under the root, called
ACME.Groups, contains classes such as Group, GroupPlan, etc.

ACME
ACME.Financial
ACME.Financial.Discounts
ACME.Groups

Now, if I'm coding something for the GroupPlan class in ACME.Groups, is it
ok (I know it's possible but is it acceptable) to return an object of type
ACME.Financial.Invoice from the ACME.Groups.GroupPlan class or should I
stick to classes contained within the local namespace boundary (ACME.Groups)
or higher (ACME)?

Any thoughts or articles discussing Namespace coding best practices (all I
could find were ones about naming standards - not enough detail regarding
class layout) would be appreciated.

- Dave

 

[Nick Malik [Microsoft]]

I do not know of an article that describes your concerns.

I am working on a namespace standard at the moment for Microsoft IT to use
internally, so that we may get some better consistency. In my case, I've
spoken with dozens of developers in different IT teams, and in each case,
they are largely sticking to a namespace structure that is much flatter than
you are implying. Namespaces aren't being used to differentiate to the
detail that you are suggesting.

I would suggest that you consider that your class library is specific to a
particular application that is tied to a specific business process within
your company. In that sense, the namespace should be
ACME.Area.Process.Application where 'Area' is the functional area of your
user's business process (Finance, Marketing, CustomerService, Product,
Partner, etc) and 'Process' is the business process that your application
supports (for example, for financial operations, you may have something like
'Invoice', 'Portal', or 'Reconciliation'). Application would be the
namespace of the application itself. Within MS, this is usually some
unrelated name or acronym... like Longhorn or Whitehorse (only the IT folks
can get pretty creative .

Using multiple namespaces within an application is done, but somewhat
sparingly. One fairly complex application I worked on had three namespaces:
one root and two child, for 400+ classes. For the most part, a namespace
tied directly to an assembly. In other words, all of the classes in that
namespace were contained in that assembly. (in the aforementioned app,
there were three assemblies).

So, the best advice I can come up with: if you are creating one assembly,
create one namespace.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

 

[Nigel Norris]

Using multiple namespaces within an application is done, but somewhat
sparingly. One fairly complex application I worked on had three
namespaces: one root and two child, for 400+ classes. For the most part,
a namespace tied directly to an assembly. In other words, all of the
classes in that namespace were contained in that assembly. (in the
aforementioned app, there were three assemblies).

So, the best advice I can come up with: if you are creating one assembly,
create one namespace.

Nick,

Interesting - it's not the approach I use. I'd find 130 classes in a flat
structure a little unmanageable. Do you use folders in your VS projects to
organize the classes at a more detailed level? When I use folders, my
namespace religously follows the folder hierarchy. So I use
folders/namespaces to represent the coarse-level logical structure of the
application (not the deployment/assembly structure). But it's probably an
approach I brought over from the Java world - I don't have much experience
of what others do.

The .NET Class Library actually seems to follow a model that is closer to
what I do - it's certainly more granular than an assembly, although maybe
not as granular as the OP's proposal.

 

[Jon Skeet [C# MVP]]

Interesting - it's not the approach I use. I'd find 130 classes in a flat
structure a little unmanageable. Do you use folders in your VS projects to
organize the classes at a more detailed level? When I use folders, my
namespace religously follows the folder hierarchy. So I use
folders/namespaces to represent the coarse-level logical structure of the
application (not the deployment/assembly structure). But it's probably an
approach I brought over from the Java world - I don't have much experience
of what others do.

I always follow that religiously too, although I don't necessarily
include the base hierarchy in the folder structure (eg if all the
namespaces in an assembly started with Foo.Bar.Baz, I would take that
as the top level of the hierarchy - so Foo.Bar.Baz.Wotsit would just be
in a directory called Wotsit under the solution).

Another habit I've brought over from the Java world is putting each
type in its own file - with the exception of short enums and delegates.
For those, I tend to have a single file, Enums.cs and Delegates.cs
respectively, which contains all the short enums/delegates for that
namespace. Of course, for larger enums (such as HttpStatusCode) I'd
devote a file just to that enum.

(On the other hand, I've also started porting some conventions from the
..NET world to my recent Java programming - in particular, prefixing
interfaces with I and using Pascal case for enums and constants, rather
than shouting.)

The .NET Class Library actually seems to follow a model that is closer to
what I do - it's certainly more granular than an assembly, although maybe
not as granular as the OP's proposal.

There certainly aren't many namespaces with huge numbers of classes -
with the notable exceptions of System.Windows.Forms which is absolutely
massive.

 

[John]

I always follow that religiously too, although I don't necessarily
include the base hierarchy in the folder structure (eg if all the
namespaces in an assembly started with Foo.Bar.Baz, I would take that
as the top level of the hierarchy - so Foo.Bar.Baz.Wotsit would just be
in a directory called Wotsit under the solution).

[snip]

My understanding from a previous employer is in Java, your namespace hierchy
should start with "tld.companyname.projectname.XXX"
For example; the Cells classes in MS Excel might be in the
"Com.Microsoft.Excel.WorkSheet" namespace.

I started doing something similar with .NET, just leaving the tld off. But
to be honest, I'm starting to think that is excessive in .NET. Maybe it was
necessary in Java because of the directory structure, and in .NET, I'm just
creating needless & cumbersome organization.

Do you guys have the tld, company, and/or project included in your .NET
namespaces?

I've got to say though, that above the initial company.project, I as much or
as little namespace hierchy as I feel comfortable with ... ussually
something like :
company.project.model
company.project.pages
company.project.controls
company.project.usersecurity
company.project.utilities.database
company.project.utilities.crypto
.... etc ...

Regards,
John

 

[Jon Skeet [C# MVP]]

I always follow that religiously too, although I don't necessarily
include the base hierarchy in the folder structure (eg if all the
namespaces in an assembly started with Foo.Bar.Baz, I would take that
as the top level of the hierarchy - so Foo.Bar.Baz.Wotsit would just be
in a directory called Wotsit under the solution).

[snip]

My understanding from a previous employer is in Java, your namespace hierchy
should start with "tld.companyname.projectname.XXX"

That's true of namespaces in Java, but not in .NET.

For example; the Cells classes in MS Excel might be in the
"Com.Microsoft.Excel.WorkSheet" namespace.

I started doing something similar with .NET, just leaving the tld off.

Yes - that's the convention.

But to be honest, I'm starting to think that is excessive in .NET.
Maybe it was necessary in Java because of the directory structure,
and in .NET, I'm just creating needless & cumbersome organization.

It's not particularly *necessary* in either Java or .NET, but it helps
to keep your namespace separate from those of other companies.

Do you guys have the tld, company, and/or project included in your .NET
namespaces?

I prefer to use company name and then project name, but sometimes just
"overarching project name" followed by a slightly more fine-grained
project name. I'd certainly feel less than entirely happy about a
commercial namespace in just one level.

I've got to say though, that above the initial company.project, I as much or
as little namespace hierchy as I feel comfortable with ... ussually
something like :
company.project.model
company.project.pages
company.project.controls
company.project.usersecurity
company.project.utilities.database
company.project.utilities.crypto
... etc ...

Yup, those are perfectly reasonable.