views:

83

answers:

2

I'm about to set out on developing a .NET class library that will be consumed by several projects. I've reached a point in my design where I'm not 100% sure which order my namespaces should be nested in. The two options I see are:

The shared project uses

  MyCompany.Common.Web
  MyCompany.Common.Data
  MyCompany.Common.Utils

with each project then using

  MyCompany.ProjectName.Web
  MyCompany.ProjectName.Data
  MyCompany.ProjectName.Utils

or I flip it around and use

  MyCompany.Web.Common
  MyCompany.Web.ProjectName
  etc

Which is considered best practice / more widely used? I've seen both around on the net. Personally, option 1 seems more logical.

A: 

I'd only use (2) if this code is project-specific, which is almost never a good assumption to make. (3) Only makes sense if these are specifically web-related; one of the nice things about .NET is that you can reuse your code with WPF/Winforms apps or just about anything else.

I'd stick with (1).

David Lively
+1  A: 

The recommended practice, I believe is as follows:

Company.Product.Functionality

If you have shared functionality, that would constitute a "product" in and of itself, in my view. My habit, in that case, is to name that product "Framework".

Consequently, we currently have:

Share.Framework.Data
Share.Framework.Data.Oracle
Share.Framework.IO
Share.Framework.Security

and so on. We also have,

Share.[Specific product].Windows
Share.[Specific product].Data
Share.[Specific product].Payroll

blah blah blah.

You get the picture. (BTW, Share is our company name.)

Mike Hofer