Namespaces... useful tools for logical design...
Jeff Atwood posted an
entry on his blog about .NET namespaces, and how he felt they were less than functional.
Almost every time I see namespaces used, they're not functional. They don't solve any collision or duplication problems for me. They're little more than vanity license plates for the author's code.
I disagree pretty heavily with this. For my company, I've used a set of namespaces that look like this:
AgnosticMedia.Common.*
AgnosticMedia.Frameworks.*
AgnosticMedia.[application-name].*
For classes that are common for all applications and all libraries, I put them in AgnosticMedia.Common. Some things are custom helper classes, and some wrap similarly namespaced .NET fx classes.
Examples are:
AgnosticMedia.Common.Logging
AgnosticMedia.Common.Data -> System.Data
AgnosticMedia.Common.Web.Services -> Microsoft.Web.Services2
Each logical library of classes gets put under AgnosticMedia.Frameworks.*, and each vertical application built on our Frameworks gets a unique namespace (i.e. AgnosticMedia.MyApplication.*). It's a logical way of managing the many classes we've created, and provides a benefit of localizing classes within their specific area.
Using namespaces as building blocks for managing code gives a way for new developers to come up to speed on our architecture. They can quickly distinguish between reusable code and app-specific code.
Also, the postfix of a namespace can be very useful as a naming convention:
AgnosticMedia.Common.Handlers
AgnosticMedia.Frameworks.*.Handlers
In AgnosticMedia.Common.Handlers, I'll put the base classes (i.e. HandlerBase) which get reused in every "framework". So, in AgnosticMedia.Frameworks.Foo.Handlers, there are classes that derive from HandlerBase.