在任何 Web 服务中更改“http://tempuri.org/”默认引用的原因仅仅是为了:
1:表明我了解命名空间。
2:为了表现专业。
如果它在技术方面没有任何好处,
我们为什么要继续更改它,这可能最终会显示一些错误。
在任何 Web 服务中更改“http://tempuri.org/”默认引用的原因仅仅是为了:
1:表明我了解命名空间。
2:为了表现专业。
如果它在技术方面没有任何好处,
我们为什么要继续更改它,这可能最终会显示一些错误。
您对您的 Web 服务没有说太多,但通常命名空间仅在与 XSD 结合使用时才有用。如果您使用的是 XSD,那么命名空间很有用,原因与它们在 C 风格语言(C#、Java、C++)中的用处相同——将您的“类”与其他程序区分开来。
如果您的 Web 服务的使用者正在尝试与另一个 Web 服务构建混搭,并且该程序员需要将来自您的服务的 XML 与来自另一个服务的 XML 结合起来,那么这些命名空间开始变得非常重要(特别是如果另一个 Web 服务有,例如你的,选择不改变默认的命名空间)。
或者,更简洁地说:
一个 XML 实例可能包含来自多个 XML 词汇表的元素或属性名称。如果每个词汇表都有一个名称空间,则可以解决同名元素或属性之间的歧义。
http://en.wikipedia.org/wiki/XML_namespace
就个人而言,我发现命名 XML 命名空间是一个将我的代码与人群区分开来的机会。花时间和精力给你的代码起一个正确的名字会给其他专业人员一种印象,即你已经花时间和精力来正确编码。可以这样想:如果您有一个带有名为 的函数的 API fUnctiontodoSomeThin()
,您可能会对它的功能感到满意,但您中的一部分人会想知道为什么程序员没有花时间和精力正确/一致地拼写和使用大写字母. 也许他/她没有花时间将他们的数据库调用包装在 try/catch 块中?这可能会导致我去寻找另一个 API(当然,其他一切都是平等的)。
我们使用命名空间作为向客户端应用程序发出信号的一种方式,即服务合同或数据合同已在发布之间进行了重大更改(即返回类型已更改,参数顺序已更改等)。否则,您的客户端应用程序将继续尝试解析返回的值,就好像它们在旧合同中一样。解析将失败,并出现令人费解且难以理解的错误消息。或者更糟糕的是,解析可以通过交换值成功(即更改数据协定中两个字符串属性的顺序)。
有关WCF 服务版本控制的更多信息。