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服務方法的建議

回答

相關問題