命名约定和命名空间

Question

If I have objects on one layer with the same name as objects on another layer, is it best to change the object names with some prefix or have new namespace and refer to them with fully qualified names? For example:

namespace Project1.Data
Object Person;

namespace Project1.Model
Object Person;

---

Data.Person.Name=Person.Name;

OR

dbPerson.Name= Person.Name;

Answer 1

I'd use namespaces and namespace aliases, eg:

Define your classes in appropriate namespaces:

namespace Project1.Data
{
    public class Person {...}
}
namespace Project1.Model
{
    public class Person {...}
}

And where you use the classes, either use fully qualified names or define an alias for the namespaces (especially usefule if the full namespace is long):

using data = Project1.Data;
using model = Project1.Model;

data.Person p1 = new data.Person();
model.Person p2 = new model.Person();
//...
p1.Name = p2.Name;

Answer 2

It depends on how often you're referring to the overloaded name.

If you use it several times in one file, then use the first way.

If you use it only once or twice, then write out the fully qualified name, so that other people won't have to go hunting around at the top of your file to figure out what object you're referring to.

Answer 3

It really depends on the frequency you're requesting each of them. Generally, I use the shortened version for the type I'm referring to most frequently, and use the longer name for the type which is less frequently used. I'd say eventually, if you end up having a lot of usages of both in the same file, that you should use namespace aliasing, but for me, that's a last resort only after the code has bloated to a point where it's hard to follow what's going on.

Answer 4

Had the same thought myself. I think chaging the name of the classes is a bad Idea. For instance I have a data access layer and a business layer. Both deal with users. So I have...

Project1.Business.User Project1.DataAccess.User

trying to think of inventive new names for the classes is a waste of time and will probably mean odd names for classes with little meaning. Naming classes can be enough of a headache already.

I agree with McWafflestix "I use the shortened version for the type I'm referring to most frequently, and use the longer name for the type which is less frequently used".

Answer 5

It's simple. Listening to the .NET framework guidelines for once actually helps (although plenty of material in the book is just plain Elements of Java style Yet Again in Redmond Wonderland)..

You should avoid similar type names in cross or intra-project/library mixing namespaces ie. mixing across domains and models in generial ( even in C++ one that is extremellly strict and powerful, it also has an incarnation in compiler, resolution and enum-style compiler crashes and problems).

Therefore even fully qualifying all the time is no fool-proof (and btw aliases and 'using' are extremely limited and cause mild duplication at best, as well as prove C# weakness in generic programming etc ).

In my experience, Data domain types are a primary target for a more appropriate name, and thus for name refactoring which is:

a) cheap (as a process in rich ASTs but simple adt-s support like in C#, right-click in IDE and feel powerful according to type-challenged dynamic Ruby fans/backers )

[can also be read as: 4.0 dynamic features sheep will blame everyone but not think about namespaces or functional JS, C-with templates(not C-with-classes), or similar ]

b) communicates the semantics better ie. the intent (ie. plumbing + support to build your own processing )

c) usually of primitive but typed nature or message ( typed not OO; ie. OO-style critique as in aforementioned book which itself breaks straight out of intro lifts all 'Models' to reference land)

d) and 'aliasing' becomes a useful artifact in cross-domain usage (which is actually possible and quite 2020-like.. ie. value-type programming )

There really are no rules but beware that you will see mixing of namespaces in development when least expected.. which means only one thing for a managed-minded dev: confusion. Plus somewhat less serious, more compile-time and IntelliNonsense errors of course..

Tough problem in all languages, so it is your design/naming issue.. Even tool vendors can mess up for machines to parse.. say output of enhanced popular IDEs based on outdated browse information; then again, others do it real well for managed languages.

Not that I am against duplicating names, there are cases (they are tough but necessary) when mixing dual + interop + representation etc other models where same name makes it more readable; ie. where duplication is a necessity of dual-usage.. but that is lower level idioms that C# is not friendly or encouraging of (re: in favour of overhead).