views:

59

answers:

2

ok...this gets confusing for me to explain, so i will show a class from one namespace and a seperate namespace...

Company.Product.Domain
(this represents the class that contains methods specific to that class, i named it "Domain" just so you can see how I'm using the same name in a separate namespace

Company.Product.Domain.Data.Contracts
(this namespace will be for all of the data contracts to be used in a WCF service)

If I am in the Company.Product.Domain class and I try to use the classes within Company.Product.Domain.Data.Contracts, when I attempt to type this out, i get to Company.Product.Domain and will not show intellisense any further. It also shows that that reference is a class instead of allowing me to get to the namespace.

I do have the Company.Product.Domain.Data.Contracts referenced in my Company.Product.Domain class.

Is it possible to have a namespace Company.Product with a class inside of it and also another namespace of Company.Product.Domain.Data.Contracts? If so, how?

Thanks

+4  A: 

Yes, it's possible. However, you should avoid it like the plague. It makes everything much more complicated.

Eric Lippert has written a series of blog posts on this very topic recently. Admittedly it's not quite the same issue - he's talking about Foo.Bar.Bar (where Foo.Bar is the namespace, and Bar is the class) but I believe you'll run into many of the same issues. Indeed, I think you may actually end up making them worse than the scenario he's describing. Please don't do it.

Jon Skeet
I actually went the route that I did to avoid the "double name" issue. Instead of Company.Product.Domain.Domain, i went with the route of separating the class from the namespace. So in the case of creating my second namespace, i wanted the rest of the data to be in the same path as my class so that the flow to the developers that used it would be the same. Also the class structures would live in the same path in the class libraries. I will read these, but the reason i'm doing what i'm doing is to avoid just what you said foo.bar.bar
dwhittenburg
@dwhittenburg: But why introduce more ambiguity? If you call it `Company.Product.Domain.DomainHelper` or something like that, there'll be no ambiguity at all, and you won't need to fight against the language.
Jon Skeet
I understand that, it just seems like a work-around rather than being able to structure the library in a logical structure. Also, I try to stay away from "Helper" objects, etc and put the objects in the correct structure with a correct naming convention. And the main thing is why can't .NET differentiate between a class and a namespace?
dwhittenburg
A: 

You can alias your Company.Product.Domain.Data namespace.

So in your Domain class, instead of

using Company.Product.Domain.Data;

try something like

using myData = Company.Product.Domain.Data;
namespace Company.Product
{
  class Domain
  { ...
    myData::Data.method();
  }
}

I'm not positive that intellisense behaves the way you want with this, but it does disambiguate the Domain class vs. Domain namespace.

East of Nowhere