views:

70

answers:

1

This is a follow-up to the question Should the folders in a solution match the namespace?

The consensus on that question was a qualified "yes": that is, folders == namespaces, generally, but not slavishly (the way java requires).

Indeed, that's how I set up projects.

But setting up source control has made me hesitate about my current folder structure. As with the .NET Framework, the namespaces in my project do not always match the deployed units one-to-one. Say you have

lib             -> lib.dll
lib.data        -> lib.dll
lib.ecom        -> lib.ecom.dll
lib.ecom.paypal -> lib.ecom.paypal.dll

In other words, child namespaces may or may not ship with the parent.

So are the namespaces that deploy together grouped in any way?

By the way, I don't use VS or NAnt — just good old fashioned build batches.

+1  A: 

I usually don't really think about this and just do "what feels right" but usually I end up using names that fit the following strategy fairly well.

I'll use the highest common namespace in the tree for the .dll name just like you seem to be doing;

with lib and lib.data this is lib so the dll is called lib. With lib.ecom and lib.ecom.paypal this is lib.ecom so the dll is called ecom.

In some cases you need to think about things a bit more for example we have the following namespaces (warning, simplistic example coming up) and we want to group them in two dll's

myapp.view
myapp.presentation

myapp.model
myapp.dataaccess

we can't use myapp because then we would have two myapp assemblies. In this case I use the name of the namespace that is most appropriate. The first might be called myapp.presentation and the second myapp.model if those namespaces are the most important.

Mendelt