关于创建webmethods的最佳实践 [英] best practices on the creation of webmethods

问题描述

我想知道是否有关于创建

webmethods的最佳做法？我会尝试解释一下这个：

我的问题是我们正在将现有的（大型）DCOM应用程序更改为使用Web服务的
，但我们有像数百种不同的方法，你可以调用和我想做的，添加一些通用的web方法，这些方法可以使用可序列化的.NET类或结构，并且那个类或结构

我们把所有必要的信息都放在必须执行的b
上。我认为这更容易，而不是添加所有

不同的方法，但我的问题是，如果建议以这种方式实现

这个？如果没有，是否建议使用

添加一项服务所有这些方法，还是最好将其拆分到不同的服务中？是

一个服务建议最多使用webmethods吗？


我必须补充一点，Web服务只能在内部使用，我的意思是

通常没有其他公司会使用我们的网络服务（我们创建客户

申请）。


欢迎任何想法或建议。


谢谢，

Bert

Hi,

I was wondering if there are any best practices on the creation of
webmethods? I''ll try to explain this a little more:
My problem is that we are changing an existing (large) DCOM application to
use web services, but we have like hundreds of different methods you can
call and what I wanted to do, is add a couple of generic webmethods that
take a serializable .NET class or structure, and in that class or structure
we put all the necessary information about the action that must be
performed. I would think this is a lot easier instead of adding all the
different methods, but my question is, if that is recommended to implement
this in such a way? If not, is it then recommended to add one service with
all these method, or is it better to split it up in different services? Is
there a recommended maximum of webmethods for one service?

I have to add that the web service will only be used internally, I mean that
normally no other company will use our web service (we create the client
application).

Any thought or suggestions are welcome.

Thanks,
Bert

推荐答案

Bert Vandenberghe写道：

Bert Vandenberghe wrote:

我们有数百种不同的方法可以打电话和我想做的事情，是添加几个通用的网络方法
>采用可序列化的.NET类或结构，并在该类或
结构中我们提供有关必须执行的操作的所有必要信息。


如果不是单独的方法，你会如何处理每个逻辑操作？

我的意思是，你可以使用某种命令模式并构建一些自定义

路由，但为什么不利用已经存在的框架将消息路由到正确的方法并保持它以这种方式分解（ASMX或

WSE）？

我认为这样更容易而不是添加所有
不同的方法，但我的问题是，如果建议

我认为这根本不容易。如果有什么事情你会让人们更难以消费，因为你的通用方法，虽然可能是无限的，但可以无限延伸，但是必须缺少类型特定的细节才能使它消失。更难以给来电者

了解任何给定操作所需的信息。对于

来自纯XML透视图的示例，您的方法实际上只需要

取xsd：any然后人们将不得不弄清楚它们是什么消息

想要发送给你以及用什么参数构成该方法而不是

直接在他们需要传递的方法上有四个参数。

如果没有，然后建议添加一个服务
所有这些方法，还是更好地将其拆分为不同的服务？


你应该根据一些逻辑分组来分解服务

的操作。例如，如果你有用户管理和订单管理

方面，你将有两个不同的服务（UserManagementService OrderManagementService）

，每个都有N个方法来处理特定的类型。 br />
是否建议最多使用一种服务的webmethods？


没有，但就像我说过你可能想要逻辑分解。

想想它就像Win32 API一样。 Win32中有很多方法吗？

但是当你想要在屏幕上画一些东西时你知道该去哪里：

GDI。现在，GDI中还有很多方法，但你知道它们都是以某种方式与绘图相关的。

我必须添加网络服务只会在内部使用，我/这意味着通常没有其他公司会使用我们的网络服务（我们创建客户端应用程序）。

we have like hundreds of different methods you
can
call and what I wanted to do, is add a couple of generic webmethods
that
take a serializable .NET class or structure, and in that class or
structure
we put all the necessary information about the action that must be
performed.
How would you handle each logical operation if not as a separate method?
I mean, you could go with some kind of command pattern and build some custom
routing, but why not leverage the frameworks that already exist for routing
the messages to the right methods and keep it broken up that way (ASMX or
WSE)?
I would think this is a lot easier instead of adding all
the
different methods, but my question is, if that is recommended to
implement
this in such a way?
I don''t think it''s easier at all. If anything you''re going to make it harder
for people to consume because your generic approach, while perhaps infinitely
extensible, has to lack type specific details that make it harder for a caller
to understand what information is necessary for any given operation. For
example from a pure XML perspective your method would really just need to
take xsd:any and then people would have to go figure out what message they
want to send you and what parameters make up that method as opposed there
being four parameters directly on the method that they just need to pass.
If not, is it then recommended to add one service
with
all these method, or is it better to split it up in different
services?
You should probably break up the services based on some logical grouping
of operations. For example, if you had user management and order management
aspects, you would have two different services (UserManagementService OrderManagementService)
each with N methods for dealing with specific types.
Is
there a recommended maximum of webmethods for one service?
There is none, but like I said you''ll probably want to break things up logically.
Think of it like the Win32 API. There''s tons of methods in the Win32 right?
But when you want to do draw something to the screen you know where to go:
GDI. Now, there''s still a ton of methods in GDI, but you know they''re all
related in some way to drawing.
I have to add that the web service will only be used internally, I
mean that normally no other company will use our web service (we
create the client application).

内部或外部我仍然认为按照我上面讨论过的方式设计

符合你的最佳利益。设计Web服务API实际上是非常好的，因为它可以归结为任何其他类型的API设计。

您仍然希望避免创建一个单一的frankenstein。 br />

HTH，

Dre

Internal or external I still think it''s in your best interests to design
it the way I''ve discussed above. Designing web services APIs is really are
no different than any other type of API design when it boils down to it.
You still want to avoid creating a monolithic frankenstein.

HTH,
Dre

嗨Bert：


如果您的分布式应用程序将在内部使用，那么使用.NET Remoting可以更好地获得
。如果你想要网络服务尝试和

使你的API变得粗糙而不是健谈（也就是说，每个

做的相当少的网络方法比有很多网络方法做了一个非常棒的功能）。此外，如果您正在使用Web服务（并且

而非.NET Remoting），因为有一天您可能会更改您的客户端

环境，那么您应该使您的服务符合WS-I Basic

简介1.0。


谢谢，

Mujtaba。


Bert Vandenberghe <恩********* @ hotmail.com>在消息中写道

news：eo ************** @ TK2MSFTNGP09.phx.gbl ...

Hi Bert:

If your distributed application is going to be used internally, you will be
better off by using .NET Remoting. Incase you do want web services try and
make your API chunky rather than chatty (that is, few web methods that each
do quite a bit is better than having lots of web methods that do one very
granular piece of functionality). Also, if you are using web services (and
not .NET Remoting) for the reason that you may change your client
environment someday, you should make your service compliant to WS-I Basic
Profile 1.0.

Thanks,
Mujtaba.

"Bert Vandenberghe" <en*********@hotmail.com> wrote in message
news:eo**************@TK2MSFTNGP09.phx.gbl...

我想知道是否有关于创建
webmethods的最佳实践？我会尝试解释一下这个问题：
我的问题是我们正在改变现有的（大型）DCOM应用程序以使用Web服务，但我们可以使用数百种不同的方法<调用和我想要做的是添加一些通用的web方法，它们采用可序列化的.NET类或结构，并在该类或
结构中
我们把所有的有关必须执行的操作的必要信息。我认为这更容易，而不是添加所有不同的方法，但我的问题是，如果建议以这种方式实现这个吗？如果没有，那么是否建议使用所有这些方法添加一项服务，还是最好将其拆分为不同的服务？是否建议最多使用一种服务的web方法？

我必须补充说，网络服务只会在内部使用，我的意思是
通常没有其他公司将使用我们的网络服务（我们创建客户端
申请）。

欢迎任何想法或建议。

谢谢，
Bert

Hi,

I was wondering if there are any best practices on the creation of
webmethods? I''ll try to explain this a little more:
My problem is that we are changing an existing (large) DCOM application to
use web services, but we have like hundreds of different methods you can
call and what I wanted to do, is add a couple of generic webmethods that
take a serializable .NET class or structure, and in that class or
structure
we put all the necessary information about the action that must be
performed. I would think this is a lot easier instead of adding all the
different methods, but my question is, if that is recommended to implement
this in such a way? If not, is it then recommended to add one service with
all these method, or is it better to split it up in different services? Is
there a recommended maximum of webmethods for one service?

I have to add that the web service will only be used internally, I mean
that
normally no other company will use our web service (we create the client
application).

Any thought or suggestions are welcome.

Thanks,
Bert

我打算做的是创建一个带有一个参数的web方法

实际上是一个可序列化的类像这样：


[XmlRoot（" GenericMessage"）]

公共抽象类GenericMessage

{

public enum Action {ADD_THIS，ADD_THAT，EDIT_ANOTHER_THING，DELETE_THIS，

ADD};

public Action type;

....

}


然后，也可以从这一个派生出更多

关于某些行动和使用的特定信息的其他类它具有相同的

webmethod，e。 g：


公共类AddSpecialMessage：GenericMessage

{

public string moreInfo;

.. ..

}


但是就像你提到的那样，对于外部用户来说这不是很清楚

你能做什么使用这种方法，但我仍然认为它比创建所有单独的方法更容易，只是如果你想改变一些东西到

方法之一，或者添加一种方法...


创建所有单独的web方法确实更好，谢谢

的建议，


Bert


" Drew Marsh" <博士**** @ hotmail.no.spamming.com>在消息中写道

news：10 ********************** @ msnews.microsoft.com ...

What I was planning to do, is creating a webmethod with one argument which
is actually a serializable class like this:

[XmlRoot("GenericMessage")]
public abstract class GenericMessage
{
public enum Action {ADD_THIS, ADD_THAT, EDIT_ANOTHER_THING, DELETE_THIS,
ADD};
public Action type;
....
}

Then it is also possible to derive other classes from this one with more
specific information about certain action and use it with the same
webmethod, e.g:

public class AddSpecialMessage : GenericMessage
{
public string moreInfo;
....
}

But like you mention, this would not be so clear for an external user what
you can do with this method, but I still think it would be easier than
creating all the seperate methods, just if you want to change something to
one of the method, or add a method...

Maybe it is indeed better to create all the seperate webmethods, thanks for
the advice,

Bert

"Drew Marsh" <dr****@hotmail.no.spamming.com> wrote in message
news:10**********************@msnews.microsoft.com ...

Bert Vandenberghe写道：

Bert Vandenberghe wrote:

我们有数百种不同的方法，你可以打电话，我想做什么，是添加一些通用的webmethods

采用可序列化的.NET类或结构，并在该类或
结构中
我们提供了有关必须执行的操作的所有必要信息。
如果不是作为一个单独的方法，你将如何处理每个逻辑操作？
我的意思是，你可以使用某种命令模式并构建一些

we have like hundreds of different methods you
can
call and what I wanted to do, is add a couple of generic webmethods
that
take a serializable .NET class or structure, and in that class or
structure
we put all the necessary information about the action that must be
performed.
How would you handle each logical operation if not as a separate method?
I mean, you could go with some kind of command pattern and build some

自定义路由，但为什么不利用
已经存在的框架将消息路由到正确的方法并保持它的分解（ASMX或
WSE）？

custom routing, but why not leverage the frameworks that already exist for routing the messages to the right methods and keep it broken up that way (ASMX or
WSE)?

我认为这更容易，而不是添加所有
不同的方法，但我的问题是，如果建议以这种方式实施这个？
我认为它根本不容易。如果你要做任何事情

I would think this is a lot easier instead of adding all
the
different methods, but my question is, if that is recommended to
implement
this in such a way?
I don''t think it''s easier at all. If anything you''re going to make it

人们更难以消费，因为你的通用方法，虽然可能是
无限可扩展，但是必须缺少类型特定的细节来制作它
调用者更难理解任何给定操作所需的信息。对于
来自纯XML透视图的示例，您的方法实际上只需要使用xsd：any然后人们必须弄清楚他们想要发送给您的消息以及参数是什么那个方法相反，直接在他们只需要传递的方法上有四个参数。

harder for people to consume because your generic approach, while perhaps infinitely extensible, has to lack type specific details that make it harder for a caller to understand what information is necessary for any given operation. For
example from a pure XML perspective your method would really just need to
take xsd:any and then people would have to go figure out what message they
want to send you and what parameters make up that method as opposed there
being four parameters directly on the method that they just need to pass.

如果不是，那么是否建议添加一个服务
使用所有这些方法，或者将它拆分为不同的服务更好？
你应该根据一些逻辑分组的操作分解服务。例如，如果您有用户管理和订单

If not, is it then recommended to add one service
with
all these method, or is it better to split it up in different
services?
You should probably break up the services based on some logical grouping
of operations. For example, if you had user management and order

管理方面，您将拥有两个不同的服务（UserManagementService
OrderManagementService），每个服务都有N个方法来处理特定类型。 br />

management aspects, you would have two different services (UserManagementService OrderManagementService) each with N methods for dealing with specific types.

是否建议最多使用一种服务的web方法？
没有，但就像我说你可能想要破解一样

Is
there a recommended maximum of webmethods for one service?
There is none, but like I said you''ll probably want to break things up

逻辑上。可以把它想象成Win32 API。 Win32
中有很多方法吗？但是当你想在屏幕上绘制一些内容时，你知道该去哪里：
GDI。现在，GDI中仍然有很多方法，但你知道它们在某种程度上与绘图有关。

logically. Think of it like the Win32 API. There''s tons of methods in the Win32 right? But when you want to do draw something to the screen you know where to go:
GDI. Now, there''s still a ton of methods in GDI, but you know they''re all
related in some way to drawing.

我必须添加Web服务只会在内部使用，我/这意味着通常没有其他公司会使用我们的Web服务（我们创建客户端应用程序）。

I have to add that the web service will only be used internally, I
mean that normally no other company will use our web service (we
create the client application).

内部或外部我仍然认为按照我上面讨论过的方式来设计它是符合你的最佳利益的。设计Web服务API实际上与任何其他类型的API设计没有什么不同，它归结为它。
您仍然希望避免创建一个单一的frankenstein。

HTH ，
画了

Internal or external I still think it''s in your best interests to design
it the way I''ve discussed above. Designing web services APIs is really are
no different than any other type of API design when it boils down to it.
You still want to avoid creating a monolithic frankenstein.

HTH,
Drew

这篇关于关于创建webmethods的最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！