tags:

views:

78

answers:

4

I tried calling a WebInvoke method called Register which returns takes in a User object and immediately just returns that object. It looks like the following:

User Register(User user)
{
    return user;
}

I am not sure what the Name and Namespace attributes do to the DataContract attribute when calling http://localhost:8081/user/register for example?

The reason I ask is because I initially had my class decorated with the DataContract attribute like this:

[DataContract]
public class User
{
   // Properties
}

When I opened up Fiddler, and sent a Post request, it said method not allowed, but when I changed DataContract to:

[DataContract(Name="User", Namespace="")]

It worked.

+2  A: 

These properties control the namespace and name of the element in the WSDL. The important part in your code is the Namespace="": this will override the default namespace (http://tempuri.org) and set its value to an empty URL.

In the end, the User class will be renamed in the WSDL from http://tempuri.org/User to simply User.

Johann Blais
But, how does it work? I mean, why does it say method not allowed when the namespace is http://tempuri.org/User as opposed to User?
Xaisoft
A: 

Based on another question and on:

I am not sure what the Name and Namespace attributes do to the DataContract attribute when calling http://localhost:8081/user/register for example?

I suggest that you are using REST service. When you called the service without setting Namespace to empty string did you define User XML with namespace xmlns="http://tempuri.org"? If not you sent to service different/unknown "data type" and it is probably reason for returned error.

Ladislav Mrnka
+1  A: 

Johann's answer, IMO is the correct one.

It works this way because when you send SOAP messages, the elements need to be namespace qualified, otherwise the WCF doesnt know how to deserialize the SOAP into the User data contract because of the namespace mismatch.

In C#, these two objects are different because they are in different namespaces...

namespace UserServices
{
    public class User
    {
        public string FirstName { get; set; }
    }
}

namespace TempuriServices
{
    public class User
    {
        public string FirstName { get; set; }
    }
}

The Namespace in XML / SOAP serves the same purpose, to make sure the objects are from the same "body" / "company" / "organization" / "domain" etc.

From what I have found, when I build SOAP services, I tend to keep all of my data contracts, service contracts, and binding namespaces in the same namespace, e.g. "http://mycompany.com/services/serviceName"

here are some great resources... Data Contract Equivalence => http://msdn.microsoft.com/en-us/library/ms734767.aspx Data Contract Versioning Best Practices => http://msdn.microsoft.com/en-us/library/ms733832.aspx

Hope this helps.

DevilDog74
I find its better to put my service contracts including operations in one namespace, and my data objects in another namespace (usually just add 'data') after it. This is because the base service namespace has some reserved words in it that you might inadvertently clash with - methodnameResponse comes to mind.
Kirk Broadhurst
+1  A: 

In additional to the other answers, the Namespace in a DataContract allows for two objects of the same name in different namespaces - i.e. versioning.

These two objects are allowed to exist as different properties in a WSDL and will be known deserializable types provided they have different namespaces:

[DataContact(Namespace = "http://myservice/v1/thing")]
V1.Thing

[DataContact(Namespace = "http://myservice/v2/thing")]
V2.Thing

Of course, they need to exist in your C# code as well for it to be valid. Or, alternatively you can change the name that the objects are known by using the Name attribute for clarity.

[DataContact(Name = "Thing")]
V1.Thing

[DataContact(Name= = "newThing")]
V2.Thing

You might use this when the class' name has changed in your project, but you need to support existing clients that use the 'old' names.

In summary, the Name and Namespace properties control how your objects will be serialized and deserialized when transmitted over the wire. When you set them, you are controlling how the client will see your data contract.

Kirk Broadhurst