I am creating a class library for a CRUD business application. The major ‘categories’ of business objects (with related data access layer objects) are:
- Maintenance (for working with master tables (master lists) in the database
- Incidents (most objects relate to a real-world incident)
- Search (obvious)
As of now, my namespaces are set up as follows:
- BusinessObjects.Maintenance.Contacts
- BusinessObjects.Maintenance.Products
- BusinessObjects.Maintenance.Classifications
- .
- BusinessObjects.Incidents.Contacts
- BusinessObjects.Incidents.Products
- BusinessObjects.Incidents.Classifications
- .
- BusinessObjects.Search.Contacts
- BusinessObjects.Search.Products
- BusinessObjects.Search.Classifications
- .
- Dal.Maintenance.Contacts
- Dal.Maintenance.Products
- Dal.Maintenance.Classifications
- .
- Dal.Incidents.Contacts
- Dal.Incidents.Products
- Dal.Incidents.Classifications
- .
- Dal.Search.Contacts
- Dal.Search.Products
Notice that every class ends up with the same name.
Is this good form?
Are there any issues that can arise from this namespace convention? Any possible confusion to another person looking/using this code?
I do realize that in the form code, one drawback will be that I will have to qualify all objects with the namespace. To me, that isn’t a big deal. I usually prefer a little explicit-ity, if that’s a word.
It seems Ok to me anyway. I would stay away from abbreviations though, that would get confusing and force people to have to know the abbreviations or look them up. Also they become unreadable and unspeakable.
One issue you might run into is names with subtle differences. With length of names being a possible issue, your eyes might gloss over the whole thing and pick up only part of it. Would there ever be a case where this happened?:
or
That contrived example might become a problem.