在.NET 2003中更新Web引用 [英] Updating Web References in .NET 2003

查看:38
本文介绍了在.NET 2003中更新Web引用的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们的开发人员在使用

Visual Studio.NET 2003更新Web引用时遇到了问题。


通常,当Web服务类(.asmx) )创建,更新Web

参考将利用disco文件更新


对应的代理文件,并反映对Web服务所做的更改。 br />
然而,使用params执行此操作的结果是,结果似乎是不可预测的,有时 - 可能是由于缓存 - 代理文件

未更新,因此导致编译代码时出现问题。


我们还注意到,例如当指定了两个out参数时 -

代理类,该方法包含一个输出参数,第二个将
更改为返回值。


我们通过手动更改reference.cs解决了这个问题。文件

网络服务。


我们想知道是否有关闭Web缓存的ny选项

服务代理文件以及它们被缓存的位置。


从Web服务传递参数的建议是什么?

我们可以对这个问题有详细的解决方案吗?

Our developers have experienced a problem with updating Web References in
Visual Studio.NET 2003.

Normally, when a web service class (.asmx) is created, updating the Web
Reference will utilise the disco file to update the

Corresponding proxy file and reflect the changes made to the web service.
However, the results of doing this with out params is that the results seem
to be unpredictable and sometimes - possibly due to caching - the proxy file
is not updated, hence causing problems compiling the code.

We also noticed that when for example two out parameters are specified - in
the proxy class, the method contains one output parameter and the second one
is changed into a return value.

We have worked around this by manually changing the reference.cs file for
the web service.

We would like to know if there is any options for turning off caching of Web
Service proxy files and indeed where they are cached.

What is the recommendation for passing parameters out of Web Services and
could we have a detailed resolution to this problem?

推荐答案

我会对此感兴趣看看是否有其他读过这个帖子的人曾经尝试过使用web方法中的参数。通常,不鼓励使用

RPC样式方法签名用于Web方法 - 更多

面向消息的方法可以帮助解决许多这些令人头疼的问题。 />

模式&微软的实践小组一直在讨论

" Document Processor"用于设计Web服务接口的模式。我用
一直在做类似的事情,但决定实施这个

模式,我已经取得了很大的成功。基本上,您在服务中创建一个

自定义类型作为请求参数,并将另一个自定义类型作为返回类型。
另一个自定义类型作为返回类型。所以你的web方法看起来像这样:
[WebMethod]

public ProcessOrderResponse ProcessOrder(ProcessOrderRequest request)

{

...

}


ProcessOrderRequest和ProcessOrderResponse都是运营商。您的服务中的类$ / b $ b专门用于将数据传递到

Web方法并将结果发送回消费者。在服务中管理这些作为
类允许您动态地将它们插入到

服务的WSDL中,与消费者签订强有力的合同,同时

同时允许与服务消费者松散耦合。


我正在努力在我的

网站上发布这个模式的工作示例,但我有点需要先完成网站。如果你愿意,我可以在我完成这件事后重新发布。


HTH


谢谢,

Denny Boynton

I''ll be interested to see if anyone else who reads this thread has ever
tried to us out parameters in a web method before. In general, using an
RPC style method signature for a web method is discouraged -- a more
message-oriented approach can help solve a lot of these headaches.

The patterns & practices group at Microsoft has been talking about the
"Document Processor" pattern for designing web service interfaces. I
had been working with something similar, but decided to implement this
pattern and I''ve had great success with it. Essentially, you create a
custom type within your service that acts as a request parameter and
another custom type as the return type. So your web method would look
something like this:

[WebMethod]
public ProcessOrderResponse ProcessOrder(ProcessOrderRequest request)
{
...
}

Both ProcessOrderRequest and ProcessOrderResponse are "carrier" classes
inside your service that are used specifically to pass data into the
web method and send the results back to the consumer. Managing these as
classes in the service allows you to dynamically insert them into the
service''s WSDL, enforcing a strong contract with the consumer, while
simultaneously allow loose coupling with service consumers.

I''m working on getting a working example of this pattern posted on my
web site, but I sort of need to finish the site first. If you like, I
can repost when I have this done.

HTH

Thanks,
Denny Boynton


感谢您提供的信息,但此解决方案违反了Microsoft

推荐的方法文档''改进.NET应用程序

性能和可伸缩性''表示你不应该这样做但是

而是使用许多简单的数据类型作为输入和输出参数。


" Denny Boynton"写道:
Thanks for the information but this solution goes against the Microsoft
recommened approach specified in the document ''Improving .NET Application
Performance and Scalability'' which says you shouldn''t do it this way but
instead use many simple data types as input and output parameters.

"Denny Boynton" wrote:
我将有兴趣看看是否有其他读过这个帖子的人曾经尝试过在web方法中输出参数。一般来说,不鼓励使用Web风格的RPC风格方法签名 - 更加面向消息的方法可以帮助解决很多这些令人头疼的问题。

模式&安培;微软的实践小组一直在谈论
文档处理器。用于设计Web服务接口的模式。我一直在做类似的事情,但决定实施这个模式,我已经取得了很大的成功。基本上,您在服务中创建一个
自定义类型作为请求参数,并将另一个自定义类型作为返回类型。所以你的网络方法看起来像这样:

[WebMethod]
公共ProcessOrderResponse ProcessOrder(ProcessOrderRequest请求)
{
...
}

ProcessOrderRequest和ProcessOrderResponse都是运营商。在您的服务中使用的类,专门用于将数据传递到
Web方法并将结果发送回消费者。在服务中将这些作为类进行管理允许您将它们动态地插入到服务的WSDL中,与消费者签订强有力的合同,同时允许与服务使用者松散耦合。

我正在努力在我的网站上发布这个模式的工作示例,但我需要先完成网站。如果你愿意,我可以在我完成这件事后重新发布。

HTH

谢谢,
Denny Boynton
I''ll be interested to see if anyone else who reads this thread has ever
tried to us out parameters in a web method before. In general, using an
RPC style method signature for a web method is discouraged -- a more
message-oriented approach can help solve a lot of these headaches.

The patterns & practices group at Microsoft has been talking about the
"Document Processor" pattern for designing web service interfaces. I
had been working with something similar, but decided to implement this
pattern and I''ve had great success with it. Essentially, you create a
custom type within your service that acts as a request parameter and
another custom type as the return type. So your web method would look
something like this:

[WebMethod]
public ProcessOrderResponse ProcessOrder(ProcessOrderRequest request)
{
...
}

Both ProcessOrderRequest and ProcessOrderResponse are "carrier" classes
inside your service that are used specifically to pass data into the
web method and send the results back to the consumer. Managing these as
classes in the service allows you to dynamically insert them into the
service''s WSDL, enforcing a strong contract with the consumer, while
simultaneously allow loose coupling with service consumers.

I''m working on getting a working example of this pattern posted on my
web site, but I sort of need to finish the site first. If you like, I
can repost when I have this done.

HTH

Thanks,
Denny Boynton



我对这个文件非常熟悉。它涵盖了一般的.NET

应用程序开发,因此,我通常同意该文档的

内容。但是,一旦您开始使用Web服务

并进入面向服务的领域,规则确实有点改变了




听起来你在网上使用非常RPC风格的界面

服务。这将促进更多健谈。与矮胖相比沟通

这项服务我可以证明,这将使你的表现明显降低

。它还可能使您试图使用的
服务的合同(WSDL)复杂化。

Ron Jacobs是Microsoft的产品经理模式&

实践小组,并在

Web服务和面向服务的体系结构上进行大量的写作和公开演讲。看看这个

链接:

http://www.ronjacobs.com/talks.htm


查看SOA模式介绍。虽然这个演讲

从整体上看待SOA,但我提出的模式(包括Document

Processor,我在最初的帖子中总结)非常好

编写高性能和松散耦合的Web服务的指导原则

也保持服务合同的完整性。


HTH


谢谢,

Denny Boynton

I''m very familiar with that document. It covers general .NET
application development and, as such, I generally agree with the
content of that document. However, once you start using web services
and enter the realm of "service-orientation," the rules do change
somewhat.

It sounds like you''re using very RPC style interfaces on your web
services. This will promote more "chatty" versus "chunky" communication
with the service and I can testify that this will DEFINITELY degrad
your performance. It can also complicate the contract (WSDL) of the
services you''re trying to consume.

Ron Jacobs is a Product Manager at Microsoft for the Patterns &
Practices group and does a great deal of writing and public speaking on
web services and service-oriented architectures. Take a look at this
link:

http://www.ronjacobs.com/talks.htm

Have a look at the "Patterns for SOA" presentation. While this talk
looks at SOA as a whole, the patterns proposed (including "Document
Processor" which I summarize in my initial post) are excellent
guidelines for writing performant and loosely-coupled web services that
maintain the integrity of the service contract as well.

HTH

Thanks,
Denny Boynton


这篇关于在.NET 2003中更新Web引用的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆