面向對象與基於參數的WCF調用？

不久之前，我開始了一個新的工作，他們一直在使用WCF處理UI和後端之間的所有數據/業務邏輯，這非常棒。面向對象與基於參數的WCF調用？

我注意到的是，這些WCF服務調用絕大多數都包含各種參數。例如，假設你有一個名爲GetFoo的服務調用。在這裏，我們如下可能會使用簽名：

public Foo GetFoo(int? ID, string Name, DateTime? fooDate)

對於一個更加面向對象的方法，你可能會改用：

public Foo GetFoo(Foo foo)

在這種情況下，代碼抓住它從Foo POCO對象需要而不是依賴於從UI傳入的特定參數集。

一方面，這提供了UI和WCF服務之間更加靈活的契約。我們可以對服務端的實現進行更改，而不會違反任何合同並更新引用。另外，我們可以有一個業務對象，直接作用於POCO而不是處理顯式的參數列表。

另一方面，目前還不清楚爲了獲得想要的對象/數據需要什麼。

哪種方法會被認爲是最佳實踐？

來源

2012-05-15 Jacob Rutherford

你可以擁有兩者，但應該清楚它們的含義。你現在擁有的兩種方法都不清楚他們做了什麼。第一招：

如果我通過一個會發生什麼：

ID = 1 
Name = "Name" 
fooDate = NULL

那麼我想問，對於ID = 1個名稱=「名稱」項或做我問ID = 1個名稱=「名稱「和fooDate = null，或者我要求id = 1或name =」Name「ro fooDate = null。

在這種情況下，至少該Id應該是一個單獨的函數。

在你的第二個示例中，你已經創建了一個我應該通過示例調用的函數。然而hou不能要求特定的NULL值。除此之外，我不會把它稱爲面向對象的評價，因爲你傳入了一個對象。 OO更多的是關於對象如何與對方進行交互。

在選擇接近時，要更明確地說明你的功能在做什麼。如果您確實需要一個可以傳入對象並構建動態查詢的函數。調用函數GetFooByFooExample。但是，如果只填寫id，請考慮GetFooById之類的函數，這會使代碼更具可讀性和自我解釋。

來源

2012-05-15 10:28:05 Peter

我在一定程度上看到了你的觀點。 –

WCF的定義是基於服務的，但是，如果您傳遞一個指示行爲的對象與顯式的服務調用來處理每個場景，則可以以OOP方式實現它。我相信這兩種方法都有積極的一面和消極的一面，儘管我的直覺是儘量利用面向對象的方法。 –

OOP是我們大多數人追求的目標。如果你意識到這一點，你需要在Foo對象上有一個新的屬性，而Foo對象有15-20個具有子方法等等的方法，這只是臭的代碼，它會爲你節省時間做正確的事情（oop imo :)）。

How many parameters are too many?更多信息

我建議你看看馬丁福勒斯本書關於重構他說什麼什麼最程序員認爲，但由於某種原因，我們不這樣做。

來源

2012-05-15 10:31:24

我總是爲單個參數進出。該參數爲我預期的數據定義了郵件（或至少郵件正文），並且返回定義了我要發送的郵件正文

您對線路上的郵件看起來像什麼保留很少控制if你使用多個參數。

契約操作是.NET方法的事實是一個實現細節。合同的目標是定義消費者和服務之間的消息結構。

來源

2012-05-15 10:40:17

我建議第三，更詳細的方法：

public Foo GetFooByName(string Name) 
public Foo GetFooByIDAndName(int ID, string Name) 
public Foo GetFooByNameAndDate(string Name, DateTime fooDate) 
public Foo GetFooByIDNameAndDat(int ID, string Name, DateTime fooDate)

等等等等。爲了幹，您可以提取公共代碼並製作一些private方法。這導致了自描述的代碼，並且可以更準確地指出錯誤（更不用說你可以改變一個方法，而使其他方法不受影響，這總是好的）。

來源

2012-05-15 10:44:26 Alex

我可以挖掘。服務調用是明確的，意圖是顯而易見的，而底層實現是內聚的。 –

如果你願意，你也可以將它們分成「partial」類，並且可以多任務地進行開發。此外，簡單的類型意味着更容易的互操作性（你永遠不知道什麼時候會出現一個野生的Java客戶端...） – Alex

面向對象與基於參數的WCF調用？

回答

相關問題