Common namespace naming suggestion

Question

I have a layered application with namespaces:

• App.Core - business layer logic services
• App.Data - data access layer store classes and data access objects
• App.Web - user interface layer

I also have business objects/DTOs. They reside in App.Objects namespace, but I dont like this naming convention. Why? Because this namespace will also have subnamespaces suffixed Objects like App.Objects.KeywordObjects. These subnamespaces can't be without the Objects suffix, because some of them will also contain classes with the same name (App.Objects.KeywordObjects will contain Keyword and Keywords classes).

I was thinking of changing App.Objects to something else. So I don't have duplicate "Objects" word. But I can't seem to find any usable word. And I don't want to use acronyms like DTO or BO.

How do you normally name your namespaces and what would you suggest I should use in this case.

Answer 1

Here are some suggestions:

• App.Contracts
• App.Entities

Giving things a good name is hard to do. The best thing I can suggest is find something that works for you and try your best to be consistent in style and tone. This is easier said than done.

“When I use a word," Humpty Dumpty said in rather a scornful tone, "it means just what I choose it to mean - neither more nor less.” - Lewis Caroll

Answer 2

Namespace depth should correlate to frequency of usage. Why not put them in App? If your application revolves around the business objects, it makes sense to keep them at or near the root.

For a practical comparison, for many business applications the business objects are analogous to keeping common types in System. They are pervasive.

Answer 3

I normally use common acronyms freely (so I wouldn't mind using App.BO, personally), but if you always have the Objects suffix in the subnamespace I think App.Business reads nicely, e.g App.Business.KeywordObjects with that "business [something] objects" phrase. (If you don't always have the Objects suffix for subnamespaces then this suggestion wouldn't work as well, as things would read strangely).

Answer 4

App.Business ?

Answer 5

I would make the following change

App.Core => App.Services

App.Objects => App.Core

or

App.Objects => App.Model

Answer 6

I'm a fan of the guidelines in "Framework Design Guidelines" by Brad Abrams et Al, which would give you:

YourCompany.BusinessArea for your business objects and YourCompany.BusinessArea.Web for your web layer. I seem to remember there was also a guideline that an object shouldn't rely on a nested namespace (but you could rely on a parent namespace)