.NET namespaces

Question

My background is primarily as a Java Developer, but lately I have been doing some work in .NET. So I have been trying to do some simple projects at home to get better at wor

Answer 1

the difference is that .net namespaces have nothing much to do with java packages.

.net namespaces are purely for managing declarative scope, and have nothing to do with files, projects or their locations.

it's very simple everything declared in a particular namespace is accessible when you include a 'using' to that namespace.

very easy.

the choice of name and whether or not/how many '.' seperators you use is entirely up to you.

VS defaults to adding .foldernames to your namespaces just to try and be helpful.

this article explains namespaces quite well: http://www.blackwasp.co.uk/Namespaces.aspx

It also has an example naming convention toward the end, although your name convention is your call! ;)

that said, most places i've worked at and people i've worked with start with company name which is sensible, as it makes typenames for that company distinct, (separate from other, libraries, vendors, opensource projcts etc.)

Answer 2

I can't claim that it's a best practice, but I often see files organized in a directory hierarchy that mirrors the namespace. If it fits your mental model of the code better, then do so - I can't think of any harm. Just because the .NET model doesn't enforce relationships between namespaces, projects, and directory structure doesn't mean you can't have such relationships if you want to.

I'd be a little leery of breaking up the code into more projects than you need, as this can slow compilation and add a little bit of overhead when you have to manage multiple assemblies.

EDIT: Note that this question is nearly a duplicate of should the folders in a solution match the namespace?

Answer 3

Indeed, the .Net environment allows you to throw your code at the IDE/filesystem like spaghetti against a wall.

That doesn't mean that mean this approach is sane, however. Its generally a good idea to stick with the project.foldername.Class approach that was mentioned earlier. Its also a really good idea to keep all of the classes from one namespace into the same class.

In Java, you can do screwy things like this as well getting all of the "flexibility" that you want, but the tools tend to strongly discourage it. Honestly, one of the most confusing things for me in being introduced to the .Net world was just how sloppy/inconsistent this can be thanks to the relatively poor guidance. Its easy to organize things sanely with a little thought, though. :)