Namespaces

[StrangerInBeijing]

Stupid as it sound, I so far did not figure out how to use Namespaces properly.

OK, I do understand the benefits, and so on, but when on start out a new project, how do you decide how to use them when you also keep in mind that new classes, migth be used in other projects as well?

Guess I'm kind of slow on "concept" kind of stuff. Took me months after I moved from VB to C#, to truely understand OOP (One thing knowing what it is, another thing to be able to visualize the whole thing). Dig me?

[jmcilhinney]

A namespace is simply a conceptual area where each type name is unique. They are generally used to group types that have certain similarities, like Data, IO, etc. When you create a new project it is its own namespace. There is usually no need to use additional namespaces within small projects. If you have additional projects that compile to libraries, you would usually have seperated that functionality because it all shares some similarity, so those projects will all also be there own namespace. Multiple projects within a solution will generally all have the same root namespace, which would represent the solution itself. You would normally only create additional namespaces within an assembly if you wanted to subdivide certain groups, like the System.Data.dll assembly contains the System.Data namespace, but also the System.Data.OleDb, System.Data.SqlClient, etc. namespaces.

[StrangerInBeijing]

So, one can decide for yourself how to name your namespaces?

Say I want to arrange my classes in directories on my disk, starting with a top level folder called CodeLib, subdirectories as Database, etc, I can for instance name a class's namespace in Database CodeLib.Database.TestClass.cs?

[jmcilhinney]

Absolutely. In the Property Pages for a project, I would normally set the Root Namespace to <SolutionName>.<ProjectName>. Others may choose to omit the <SolutionName>, particularly if there is only one project in the solution. Every class, and indeed other type as well, that you create within your project is then a member of that namespace by default. If you then want to make a type a member of a child namespace you simply put it inside:

Namespace <NameSpaceName>
 
End Namespace

and it is then a member of <SolutionName>.<ProjectName>.<NameSpaceName>. How you choose to make those subdivisions is completely up to you. Like I said though, you should be using namespaces to group only types that share some sort of similarity.

[StrangerInBeijing]

you should be using namespaces to group only types that share some sort of similarity.

...that was my only initial motivation to care about namespaces in this particular case.

Thanks for the help. What I did was to create a sample app and play around with it. Should have done it ages ago.

[mendhak]

I generally create namespaces with a starting name as the company name, for 'belongingness'. It's also common practice.