Nick
Mon Aug 15 21:00:47 CDT 2005
I do not know of an article that describes your concerns.
I am working on a namespace standard at the moment for Microsoft IT to use
internally, so that we may get some better consistency. In my case, I've
spoken with dozens of developers in different IT teams, and in each case,
they are largely sticking to a namespace structure that is much flatter than
you are implying. Namespaces aren't being used to differentiate to the
detail that you are suggesting.
I would suggest that you consider that your class library is specific to a
particular application that is tied to a specific business process within
your company. In that sense, the namespace should be
ACME.Area.Process.Application where 'Area' is the functional area of your
user's business process (Finance, Marketing, CustomerService, Product,
Partner, etc) and 'Process' is the business process that your application
supports (for example, for financial operations, you may have something like
'Invoice', 'Portal', or 'Reconciliation'). Application would be the
namespace of the application itself. Within MS, this is usually some
unrelated name or acronym... like Longhorn or Whitehorse (only the IT folks
can get pretty creative :-).
Using multiple namespaces within an application is done, but somewhat
sparingly. One fairly complex application I worked on had three namespaces:
one root and two child, for 400+ classes. For the most part, a namespace
tied directly to an assembly. In other words, all of the classes in that
namespace were contained in that assembly. (in the aforementioned app,
there were three assemblies).
So, the best advice I can come up with: if you are creating one assembly,
create one namespace.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Dave Slinn" <dslinn@accesscomm.ca> wrote in message
news:eUcB4R2nFHA.3936@TK2MSFTNGP10.phx.gbl...
> Any advice on how to organize my core class library project into
> sub-namespaces? What are the general rules of thumb regarding
> cross-namespace references? Can I have a class in namespace A have a
> function or a property that returns a class from a different namespace?
>
> For example, lets say I have a root namespace called ACME for my class
> library project. Under the root namespace are classes such as Individual,
> Address, etc. I also have a namespace defined for financial classes,
> called ACME.Financial, which contains classes such as Invoice and
> Transaction. Under Financial is a subnamespace called Discounts
> (ACME.Financial.Discounts). A second namespace under the root, called
> ACME.Groups, contains classes such as Group, GroupPlan, etc.
>
> ACME
> ACME.Financial
> ACME.Financial.Discounts
> ACME.Groups
>
> Now, if I'm coding something for the GroupPlan class in ACME.Groups, is it
> ok (I know it's possible but is it acceptable) to return an object of type
> ACME.Financial.Invoice from the ACME.Groups.GroupPlan class or should I
> stick to classes contained within the local namespace boundary
> (ACME.Groups) or higher (ACME)?
>
> Any thoughts or articles discussing Namespace coding best practices (all I
> could find were ones about naming standards - not enough detail regarding
> class layout) would be appreciated.
>
> - Dave
>