Geek Answers Handbook

.NET: How do you decide how to structure your namespace?

I am wondering what recommendations you use to determine the structure of your namespaces. When do you decide something guarantees its own namespace?

I read a forum or article on the forum that it’s best to go to a small tree with as few simple names as possible, but I don’t remember the reasoning behind it or the link.

Now I'm just doing what feels good, but would prefer more specific recommendations, especially to explain to newer developers.

Thanks.

+4
source share
3 answers

I follow a small tree, myself. One of the negative consequences of multilevel namespaces is the spread of the same type and the same type in the same project (differentiated only by their different name places) or even worse: the classes of the same name and differently functioning in the same project. Having only one namespace in a project forces developers to give each individual class a good, self-descriptive name.

Having multiple folders in a project is still a good idea, however (for organizational purposes), and I would like Visual Studio to have an option so that classes added inside a subfolder cannot automatically add folder names to their namespaces (such version may be in later versions of 2005). I work on this by always adding new classes at the root level and then dragging and dropping them into the appropriate folders.

+2
source

I use several folders (multi-level folders) in the solution and several times in projects.

I map solution folders to namespaces, sometimes providing projects with a sub-namespace.

Most of my projects have one namespace.

eg.

Company.Product.Initialization // (exe project) Company.Product.Data.Interfaces // interfaces (dll) Company.Product.Data.Collections // collections (dll) Company.Product.Data.Binding // binding logic (dll) Company.Product.Data.Binding.Tests // unit tests for above (dll) Company.Product.Data.Serialization Company.Product.Data.Serialization.Tests Company.Product.Model // (dlls) Company.Product.Gui.Controls // (dlls) Company.Product.Gui.Windows // (dlls) Company.Product.Gui.ModelView // (dlls) Company.Product.Gui.Logic // (dlls)

I agree with MusiGenesis on the importance of good names, and also suggest reading MS recommendations (preferably for C # 3.5 or 4.0).

0
source

More articles:


All Articles