Namespaces for Classes
So I am working on the self-validating text box, and the first issue I ran across was the namespace naming convention. Just what the heck should the namespace be for these controls? I finally settled on something similar to the Microsoft convention – At least I know it works.

MyCompany.Web.UI.WebControls

Will I ever have a need for classes under my web namespace that are not web controls? Well – I hope so. I have in mind a web counter since so many of my customers request one, but lets save that for another day. In the meantime I hope to keep my namespaces as flexible as possible.

In the back of my mind, I knew that I would only build the dll at the webcontrol level. This way I won't dump a whole bunch of 'extra' functionality that the project doesn't need. Of course this means more maintanance.

How do you guys typically do this?

Comments

# re: Namespaces for Classes
Gravatar I have developed component libraries in the past and always abide by .NET-like namespaces (even in my UI projects). I find that this allows other developers to familiarize themselves with your system faster. Outside of the project-specific namespaces, however, I use a company, tool suite, product namespace. So, for the web controls you'd have this:

<Company>.<Suite>.<Product>.Web.UI.WebControls

Obviously, you'll have a few namespaces out of the ordinary, but this should work in most cases. For instance, I typically have a Business.Services and Business.Delegates for my business service (SOA support) and business delegates (business logic).

The question I've come to is how and when do you need to break classes out into sub-namespaces or even parent namespaces with separate functionality. That seems like more of an interesting question to me.
Left by Michael Flanakin on 8/18/2005 10:18 AM

Leave Your Comment

Title*
Name*
Email (never displayed)
 (will show your gravatar)
Url
Comment*

 

Preview Your Comment.