Assembly name vs. Namespace name

  • Thread starter Thread starter Vagif Abilov
  • Start date Start date
V

Vagif Abilov

I've recently read guidelines where it is recommended to organize projects
in directories that match assembly names. For example, if I have an assembly
called MyCompany.MyProduct.Data, then I should have the following folder
structure on my local disk and in version control system:

MyCompany
MyProduct
Data

Inside the innermost folder I will place a C# project that is called
MyCompany.MyProduct.Data.csproj

Then for each type/class defined in the project I will have a file with
class name.

I believe this is a very consistent approach, although I find recommendation
to create one file per enumeration type to be a bit extreme. However I am
bit confused if I should use assembly name or namespace name as a base for
my folders, and if assembly names and namespaces should have different
structure at all. What is your approach to namespace naming? Are there any
reasons they should not be different, i.e. a namespace should not be
assigned a name of its assembly? I have looked at our projects and in
principle it looks that we can unify their namespaces, so they will match
respective assembly names. It this a good idea?

Vagif Abilov
vagif @online.no
Oslo Norway
 
Vagif Abilov said:
I've recently read guidelines where it is recommended to organize projects
in directories that match assembly names. For example, if I have an assembly
called MyCompany.MyProduct.Data, then I should have the following folder
structure on my local disk and in version control system:

MyCompany
MyProduct
Data
Click to expand...

<SNIP>

As with many things it is a matter of personal choice, but my 2p is that
organising into directories like that
based on assembly names is horrible! It's common in Java because a
dot-seperated typename is resolved
by traversing corresponding directories, but I haven't seen it in any .NET
projects.

I'd instead go with a seperation based on functionality of the code. This
may or may not match your
namespaces. Dividing into core/gui/tests is one strategy that I use often.
YMMV.

Ben
 
But do your assembly names match namespaces?


B S Wootton said:
<SNIP>

As with many things it is a matter of personal choice, but my 2p is that
organising into directories like that
based on assembly names is horrible! It's common in Java because a
dot-seperated typename is resolved
by traversing corresponding directories, but I haven't seen it in any .NET
projects.

I'd instead go with a seperation based on functionality of the code. This
may or may not match your
namespaces. Dividing into core/gui/tests is one strategy that I use
often.
YMMV.

Ben
Click to expand...
 
Vagif Abilov said:
But do your assembly names match namespaces?
Click to expand...

No, I would typically have many sub-namespaces in a given assembly. For
instance:

ben.core.dll:
- ben.core
- ben.core.remoting
- ben.core.logging

ben.gui:
- ben.gui.serialisation
- ben.gui

This is because my applications are usually driven like this. If you would
like to say, divide your logging stuff out for future use, by all means
refactor this into a seperate assembly. In this situaiton I would choose to
put it into a different directory based on it's function - rather than it's
namespace or assembly name.

Again, just my suggestion.

It might be worth downloading some large .NET open source frameworks and
seeing if you like their internal organisation. That's what I did!

Ben
 
Thank you Ben. I am currently looking at some examples from large projects.
Looks like we will go for "one namespace per assembly" approach.

Vagif
 
Vagif Abilov said:
Thank you Ben. I am currently looking at some examples from large
projects. Looks like we will go for "one namespace per assembly" approach.
Click to expand...

I think you should reconsider.

I have found that going for a one-one relationship between assemblys and
namespaces almost defeats the purpose of using namespaces in the first place
(except for solving ambiguous classnames).

For large SOA projects I typically define assemlies per Facade, ie a can
have a customer and a order dll.
If I want to have entity validaors in several tier and or datasets on
several tiers I wrap them in separate assemblies.

However, my namespace/assembly group might look something like this (a
simple example):

customer.facade (customer.dll)
customer.data (dto.dll)
customer.validation (validator.dll)
order.facade (order.dll)
order.data (dto.dll)
order.validation (validator.dll)

Hence, I use namespaces to structure my code and assemblies to structure my
tiers and layers.

Hope this helps
- Michael S
 
Back
Top