Question

使用这些方法签名创建公开的Web服务是否可接受（即标准）：

ThisMethodDoesSomething(ComplexType param)

ThisMethodDoesSomethingElse(AnotherComplexType param)

或者这个：

ThisMethodDoesSomethingAndSomethingElse(string xml)

正在执行的操作取决于传递给单个do-it-all方法的XML字符串？我一直和前者在一起，但我的同事更喜欢后者，我在开始一个新项目之前试图权衡两种策略的利弊。对于公众来说，哪个更容易被接受和更容易？为什么？

Answer 1

我永远不会发送XML字符串。首先，“XML”与“string”不同。他们不遵循相同的规则。

任何合理的客户端都可以递归地接受由基本类型和列表或基本类型数组组成的复杂类型（C＃语法）：

public class ComplexType1
{
    public int IntegerProperty {get;set;}
    public int[] ArrayOfIntegers {get;set;}
    public List<int> ListOfIntegers {get;set;} // Same as ArrayOfIntegers
}

public class ComplexType2
{
    public ComplexType1 CT1 {get;set;}
    public List<ComplexType1> LCT1 {get;set;}
}

坦率地说，任何不能处理上述事情的客户都应该退休。

Answer 2

以前我会优先考虑后者，因为我不确定，如果在跨平台的情况下，每个SOAP客户端都能够正确地使用复杂类型。所以我认为一个SOAP调用，只需要并返回（XML-）字符串将不会给我带来麻烦。与此同时，我经历过，第一种方法通常没有问题，至少.Net与JAVA / AXIS互操作，反之亦然。我仍然在注意使复杂类型不太复杂。

我假设ThisMethodDoesSomething()和ThisMethodDoesSomethingElse()是原子操作？如果不是这种情况（ThisMethodDoesSomethingElse()需要调用ThisMethodDoesSomething()来执行），那么第一种方法就是不行。

Answer 3

我更喜欢（这是一个有效的词，因为没有标准），这是一个解释行动的复杂XML字符串。您可以在my open-source project。

中看到此信息

我喜欢它的一些原因......

您的行为是可以弯曲的解释性语言。
行动可以复合成一次网络旅行。
XML允许扩展功能集，同时不破坏过去的功能。
XML层次结构允许操作对服务器端的操作起作用。

Answer 4

乍一看，您的问题听起来像粗粒度与细粒度接口的问题。另一方面，如果你知道我的意思，我觉得第二种方法是粗略到极致。你失去了所有的类型检查。你使实现变得非常困难 - 在支持代码中你需要很多if case才能真正弄清楚请求的内容。该方法将返回什么？我猜你是否只是将一个字符串作为参数，你将返回另一个字符串。因为它是一个String，并且我猜它是XML文档的字符串表示，所以你必须解析部分支持代码。随着界面越来越大，我认为这些将变成上帝的方法。列表继续：）

作为旁注，请不要认为我提倡非常精细的接口。两者之间必须保持平衡。对我来说，经验法则是总是传递一个元素。

Answer 5

我通常会创建一个xml架构来描述将构成我的界面的消息。然后，使用xsd到类生成器，如Castor或Microsoft xsd.exe，我创建了我的实现类。

Web服务：单字符串参数或复杂类型参数

5 个答案: