JsonServiceClient方法和IReturn

Question

在我們的團隊中，我們使用請求和響應DTO，通過業務邏輯程序集的層次結構（超出了隔離的DB DTO）。

我們要求在業務邏輯層沒有SS依賴關係。

所以我們不使用IReturn或IReturnVoid接口。我們只使用簡單的c＃對象而沒有繼承。

至於路由，我們在AppHost.Configure中使用Fluent API，基本上創建一個路由表。

在我們的例子中，ServiceStack表現得非常好。

我們的Service.Model可以從業務邏輯層使用，無需依賴。

服務函數實際上是一個很薄的包裝器，調用業務邏輯函數以返回響應DTO。

但是JsonServiceClient.Get函數只接受IReturn對象的參數，或者直接接受URI。

它不接受作爲參數的對象，如Post函數。

有什麼建議嗎？

更新1。

mythz，

關於IReturn，不幸的是，在我們的例子還有未使用的業務邏輯模塊，

甚至更​​輕SS依賴性要求。

服務功能是調用業務模塊的薄包裝器。

兩層之間的鏈接只是請求和響應DTO。我們非常喜歡這種方法。

是的，它們是「消息操作」，但它們也作爲應用程序層之間的消息。

另外我的客戶主要是jQuery的Ajax，而不是C＃。由於移動，絕大多數人傾向於Jquery Ajax。

因此，在我們的例子中，我們只能使用沒有用IReturn標記的對象。 ServiceStack的表現非常好。

Answer 1

該API僅接受IReturn<TResponse>以明確它只接受和使用請求DTO的，而不僅僅是任何DTO或對象。請求DTO是「消息操作」，不應該被重複用於其他任何事情，DTO類型可以是，但不是請求DTO，它是你的external facing service contract，不應該與任何其他問題耦合。

的DTO屬性，如[Route]，IReturn<T>，[Api]，[Restrict]等是不能在C＃來表達，但就像定義DTO屬性的類型，它的靜態元數據描述服務，如果只是額外的元數據你將它們歸屬於DTO，然後它們在客戶端也變得可共享和反思。例如。ServiceClients將只能使用由[Route]定義的自定義路由，因爲這是客戶端唯一的信息，如果沒有，它將最終回退到使用預定義的路由。

ServiceStack鼓勵定義IReturn<T>標記，因爲它允許您通過查看Request DTO來推斷更多關於服務的信息，確保服務在返回相同類型（良好實踐）時受到限制，並集中服務返回的內容而不是擴展到不同的（更詳細/非DRY）呼叫站點，這也意味着如果您更改響應服務返回，您將得到編譯器反饋哪些呼叫站點需要更新。不是每個人都知道這個信息/行爲，這就是爲什麼ServiceStack希望通過鼓勵使用IReturn<T>標記來鼓勵這個「成功之坑」的發展，所以不是每個人都必須這樣做。

至於依賴關係，您的DTO應該需要引用的唯一依賴項是ServiceStack.Interfaces.dll，它故意爲輕量級，無impl的dll。在V3這需要引用ServiceStack.Common的NuGet PKG但V4我們將提供一個獨立的ServiceStack.Interfaces的NuGet PKG提供最小/最輕的依賴你的DTO的可以參考一下。