Is this the good pratice to name the namespace according to the directory name

I have a directory structure to store the source files. Is this the good practice to name the naming space according to the directory structure?

Like

Models\model.cs
开发者_开发技巧Data\data.cs

One is defined in namespace Models One is defined in namespace Data

Yes, that's the typical approach, and it's also one that's supported by tools such as ReSharper.

The difference between this and the Java approach is that you don't add directories all the way down from the top - just from the default namespace for the project. So for example, suppose we were creating Foo.Bar.Baz.Model and Foo.Bar.Baz.Data, the C# and java solutions might be:

C#:

Foo.Bar.Baz
  Foo.Bar.Baz.csproj defining a project with default namespace of Foo.Bar.Baz
  Model\
        SomeModel.cs
  Data\
       SomeData.cs

Java:

src\
    foo\
        bar\
            baz\
                model\
                       SomeModel.java
                data\
                     SomeData.java

yes is the usual practice, but you also put the project name before the directory name so you will have: myclasslibraryname.Models.Model and myclasslibraryname.Data.Data

Yes. It is a common practice in Java (at least, the source code I've looked at for big projects has almost always been structured this way). Not as common in C# from what I've seen, but there's nothing keeping you from doing it, and it helps you find the code a lot faster.

You'll probably want a deeper namespace hierarchy than just one level though. It is common to preface it with your organization or group name, the project name, the library/program name, then code architectural names (like Model, View, Data, etc). Whatever makes the most sense for whatever scope the source code of your project will live.

Generally I think it is a good practice. When you do it in such a manner, while going through the code, you can generally associate or easy to locate and get to know where your code file is coming from.

This is also a good practice in terms for maintaining the code. Some new user comes in, he can just see the namespace and identify where the code files are located or needs to be searched.

I don't know really if this is good or not. But I name it like this. I defined categories for the different modules.

Like this: Company.Common Company.Common.Web

Company.Windows Company.Windows.Services

Common represent a directory. Inside it I created a solution with VS2010. Inside the solution I create a project for each part and therefor the subdirectories for the project and if the project is complex, more sub dirs for the existing classes inside the dll.

There I have a good overview in all views (dir - view and project view - code view ).

This is a convenient convention for many projects, and one which some tools support or expect.

However, this isn't the full story. Although it's a good default, I don't think it should be regarded as inviolable best practice, because there are some circumstances which might motivate doing things another way. Additional factors to think about include:

• Unnecessary namespace proliferation and deeply nested namespace hierarchies can be a pain for users of your types. In a large library you may want to start organising the source code files into some folder structure before you feel the need to impose multiple namespaces on your clients.
• Related to this, namespace hierarchies in .NET are supposed to work such that dependencies between types go from child namespace to parent, not the other way around. This isn't always the natural way to organise source code into folders/directories. For example, one often sees people creating namespaces such as MyNamespace.Foo.Common containing utility types used both by types in MyNamespace.Foo.Bar1 and those in MyNamespace.Foo.Bar2. It seems sensible to them at the source code organisation level, but it breaks the namespace dependency convention.
• Sometimes you may want to provide additional functionality by adding some types to a library namespace by distributing a supplementary assembly rather than releasing a completely new version of the full library assembly. It's likely to be more convenient to keep source code files for the respective assemblies separate from each other in the repository, rather than to store them together just so as to keep all types for the namespace in the same folder.

In short, I'd say follow the usual practice unless you have a good reason to do otherwise. But don't let it deter you, if you have a good reason to make use of the fact that Namespaces can provide a grouping of types completely orthogonal to their grouping into deployable assemblies and the source code which builds those.