服務層驗證 - 拋出異常或包裝ServiceResponse類型

這是一個通用的體系結構問題，而不是對代碼示例或特定代碼解決方案的請求。服務層驗證 - 拋出異常或包裝ServiceResponse類型

在一個多層應用程序，我們有handlings服務層驗證的兩個主要選擇：

PRO這種方法是輕量級的服務層的簽名，但是，從另一方面存在的異常被拋出各地的地方，因爲例外本身潛在的開銷不是一個可能要重新考慮最廉價的選擇這個選項。

介紹ServiceResponse包裝類型

類型可能是這樣的（僞碼）：

class ServiceResponse{ 
    boolean IsOk; 
    array ErrorMessages; 
    object OkResponse; 
}

這也符合REST服務（儘管問題與他們無關），Http響應消息實際上充當ServiceWrapper的狀態碼和內容。

你喜歡在服務層中使用什麼方法，爲什麼？

來源

2017-07-09 dee zg

我個人比較喜歡服務層的例外。主要是因爲你必須趕上並採取行動。如果你返回一個對象，你必須手動檢查狀態（也許會忘記它），但是除非你被迫採取行動。 – centaurio

是的，對於例外情況來說，這是一個非常好的例子，在我看來，也許有一個很好的理由，因爲它們不能被忽略。另一方面，我不知道'遺忘'是確定實施方向的一個很好的理由，無論是這樣或那樣。 –

這是真的。但是忘記檢查返回是否有效（主要不是空）會在大多數情況下破壞你的應用程序（nullpointerexception），因此應該避免。 – centaurio

如果Iam正確理解你的問題，你的服務層就是你的UI層注入或依賴的某種庫。在這個級別拋出異常更好。如果您決定**將服務層進行物理分離並通過API層（REST）公開它。您始終可以在API層捕獲這些異常，並使用正確的http代碼和異常消息返回http響應。所以是堅持以例外開始。

2017-09-17 17:20:43

回答