How to organise namespaces

  • Thread starter Thread starter M Shafaat
  • Start date Start date
M

M Shafaat

Hi,
I want to develop a number of generic components which I intend to use in
different applications. Is it a good idea to put all these generic
components in one and the same namespace, e.g. named GenApplCtrls, without
any regard to whether or not the components have any functionality in
common?


Which principles should be considered when deciding which classes to belong
to a namespace?


Regards
M Shafaat
 
You are going to find that this is usually a matter of preference. For
me, I like the namespace to be pretty specific about what is in them.

For example, in your setup, you might have some common components for
data access, and some which are actual user controls. In this case, I would
recommend breaking them out into two separate namespaces, with a common
root.

Hope this helps.
 
some namespaces where I work:

Infocus.Shared <-- 'common' components, utility classes etc. This class does
not reference any other of our libs.
Infocus.Diagnostics
Infocus.ApplicationName <-- represents an application library, one which
contains:
Infocus.ApplicationName.UI.Forms
Infocus.ApplicationName.UI.Controls
Infocus.ApplicationName.Components
Infocus.ExportApi <-- an example 'api only' assembly. This is not
application specific, it merely contains a shared API used by one or more
applications.
Infocus.ApplicationName.Services <-- server-side assembly that provides
services specific to an application.
Infocus.Services <-- more generalized server-side assembly that provides
services specific to no application.
Infocus.Forms <-- Similar to System.Windows.Forms, it contains Components,
Controls submnamespaces and the root contains basic Form subclasses.

We do not create namespaces specific to content, for example, if we subclass
a grid component we don't go and create an assembly or new namespace, it
would automatically find itself in a more general namespace such as
"Infocus.Forms.Controls" with an obvious name like "UltraGridSubclass".

Also, I've found it helpful to make use of default root namespaces
cross-assembly. For example, consider I wrote my own browser, i might have
these three assemblies:

Infocus.Browser.dll
Infocus.Browser.Shared.dll
Infocus.Browser.Services.dll

Infocus.Browser would be a common namespace, this means that in all 3 dll's
ALL components by default are located at Infocus.Browser.*

Shared and Services libraries both have a subnamespace defined as
Infocus.Browser.Services, the shared lib contains interface definitions,
whereas the service lib contains the implementation code that runs at the
server.

Hope that helps,
SEWilson

----- Original Message -----
From: "M Shafaat" <[email protected]>
Newsgroups: microsoft.public.dotnet.languages.csharp
Sent: Friday, April 01, 2005 11:36 AM
Subject: How to organise namespaces
 
Hi,
I want to develop a number of generic components which I intend to use in
different applications. Is it a good idea to put all these generic
components in one and the same namespace, e.g. named GenApplCtrls, without
any regard to whether or not the components have any functionality in
common?


Which principles should be considered when deciding which classes to belong
to a namespace?


Regards
M Shafaat
Click to expand...

I mostly do it like this: a WebLog web control has the namespace
CodersLab.Web.Controls (generated dlml is called
CodersLab.Web.Controls.WebLog.dll); a windows TreeView control has
CodersLab.Windows.Controls namespace (generated dlml is called
CodersLab.Windows.Controls.TreeView.dll).

For general stuff without UI it's something like CordersLab.Utilities.

Business layers in an application could be called
CodersLab.ApplicationName.BusinessServices and
CodersLab.ApplicationName.BusinessEntities.

I try to create seperate dll's for each control I make. This way, if
someone want to use one of my controls, he just has to reference a
small dll; I think this is in contradiction to what Shaun wrote.

I guess that it's all about taste :)
 
Which principles should be considered when deciding which classes to
belong to a namespace?
Click to expand...

I have a dozen or so "generic" classes all of which have the namespace
"shared", for no other reason that they are shared in Visual SourceSafe.
These include: a SQL Server DAL, mail, encryption, validation, event log
handling, registry handling etc. When I start a new project, I just share
what I need into it from VSS.

Above that, namespaces will depend on the individual project, but I try to
make them relate to the specific business entities as far as possible. E.g.
for a "vanilla" sales system, I might have namespaces like Customers,
Products, Sales etc
 
Back
Top