WCF Web服务方法的建议

我一直在负责实施，可用于许多不同的事情Web服务方法（读：没有要求存在）和任何客户将不必更改界面这里的方法是什么应该看起来像WCF Web服务方法的建议

[DataContract] 
    public class Status 
    { 
     [DataMember(Order = 0)] 
     public long Code 
     { 
      get; 
      set; 
     } 

     [DataMember(Order = 1)] 
     public string Message 
     { 
      get; 
      set; 
     } 
    } 

[DataContract] 
    public class Data 
    { 
     [DataMember(Order = 0)] 
     public string Name 
     { 
      get; 
      set; 
     } 

     [DataMember(Order = 1)] 
     public string Value 
     { 
      get; 
      set; 
     } 
    } 

public Status InitiateTransaction(long txnTypeId, Data [] txnData);

的想法是，客户端会根据什么类型的“交易”，他们要发起的传递不同事物的数据阵列英寸这会比仅仅创建一些执行特定事情的不同专业方法有什么好处？

来源

2009-04-20 Nick

如果市民建议你实现这个受羞辱，告诉他们，这个模式是懒惰的明确迹象。他们无法弄清楚行为的要求是什么，所以他们指定了一种方法;他们不会因为弄清楚数据需求而烦心，所以他们决定使用名称/值对。

只有一种情况下，我发现这样的事情是有用的。我在定义一个接受一段XML并返回一段XML的Web服务时看到了一些价值，希望至少受到XML Schema的限制。当服务意图与某些其他服务或其他代码片段进行交互时，这些用法可以用于XML文档。一个例子就是一个EDI场景，当时文档格式已经被行业标准或者协议所定义，并且web服务实际上只不过是一个代理服务的代理，它将完成真正的工作。

它看起来不像你的例子有这个借口。

来源

2009-04-20 23:49:05

好了，好处是 - 它有点“通用” - 这取决于被传入

但是，这是其最大的弱点也是如此，在同一时间。既然它是非常通用和多用途的，你真的不能真正执行很多约束和/或有效性检查。

我看到在很多地方这种方法 - 网络服务，数据库模式 - 他们通常工作的优良两个或三个独立的“东西”，而是开始土崩瓦解他们得到更加复杂。

我会强烈建议创造你想要做的每一件事情具体，完善的检测方法。

马克

PS：还 - 扩展现有服务与其他方法的同时不改变任何现有的接口可以很容易地，做没有任何变化的客户， - 所以你总是可以轻松地扩展您的随着您的需求增长而提供服务，而不破坏向后兼容性。

来源

2009-04-20 19:06:43

我绝对同意你的看法。我试图想出为什么这是一种不好的模式的原因，所以我可以向其他某些人证明 – Nick 2009-04-20 20:02:01

你也有这样的服务为你的东西上面承载Web服务。如果您要在SOAP端点上承载此类客户端，您的客户端将为您提供一个“代码”和一条“消息”，IIS或您用于托管Web服务的任何东西都将解释为HTTP消息并调用正确的HTTP处理程序。 WCF SOAP处理程序将获得该消息，该消息实际上只包含另一组代码和消息，SOAP堆栈将调用正确的服务方法并将消息传递给该消息，然后再打开该消息，得到它的代码和消息，并呼吁正确的事情。

您需要在任何情况下在某个时刻实施这些方法。所以我会问你的主管的问题是为什么不使用已经是提供者的通用代码/消息系统，标准化和什么，以及为什么他们应该通过让你实现自己的TOP来浪费你的时间？

同样如Marc所述，在现有客户端上为接口doesn't force any changes添加更多方法。

来源

2009-04-23 22:11:48

WCF Web服务方法的建议

回答

相关问题