代碼設計：業務邏輯和表示層分離與狀態信息

Question

長話短說...

我希望我的客戶（客戶端在「服務消費者」，如REST）獲取有關什麼的狀態信息業務層做了或沒有做。只是返回一個空對象或者只是空值並不完全是描述性的。任何事情都可能發生。

該死的 - 我做了這樣一個很好的UML序列圖來說明問題，但StackOverflow上不會讓我郵寄由於口碑點不足：'（

這個問題可能是世界上最古老。但是我沒有找到一個令人滿意的答案。 我可以解決這裏描述的解決方案How Do You Communicate Service Layer Messages/Errors to Higher Layers Using MVP?，但它並沒有讓我跳過循環。在整個地方拋出異常聽起來不是一件好事。例外是昂貴的。我也需要創造一個例外，相當多的「這可能發生」的場景。

*** *所以問題是......你設計「通用返回值」還是拋出異常？****
不幸的是我到目前爲止還沒有找到答案......這就是你開始玩的地方:)

我會繼續，並在其中放置一個狀態碼，一條消息和實際請求的類型T的信息。 我們假設這個通用返回值是「ServiceResult」。

考慮我提出：

• 好了，所以我的業務層方法都返回ServiceResult對象。好。
• 這非常容易處理 - 只要您調用的公用方法發生所有業務層次魔法。那麼 - 它沒有。通常不是。
• 因此，您要麼必須使ServiceResult可以訪問所有私有方法，要麼將其作爲參數傳遞。你不想傳遞100次......相信我。
• 這就是當你決定添加一個ServiceResult屬性到你的「控制」業務類。但是請等待......您不要在c＃中添加通用屬性。因爲它不是支持的功能。
• 接下來是什麼？使用「對象」作爲屬性呢？幾乎......你不想一直投射，你首先不知道要投什麼，因爲T可以是任何東西。而你私人的方法（從你最初調用的公共方法下來的3個級別）根本不知道類型 - 當然你也可以將它作爲你的類的一個屬性。它仍然是一個糟糕的設計我猜..
• 假設你解決了這個問題，你需要檢查ServiceResult.Status每次在下一個方法被調用之前，如果ServiceResult尚未處於「故障」狀態和進一步處理沒用。當然，你可以把所有的魔法在運行（Func鍵FUNC）方法，但如果你在這一點上......在最新的...你重新開始考慮使用異常:)

基本上就爲什麼我認爲人們只是拋出異常並在最高級別捕捉到它們（在您的業務邏輯中 - 而不是在控制器中）。

有沒有設計模式，我不知道這個問題？

Answer 1

遍佈各地的投擲異常聽起來不是一件好事。

當然不是。發生異常情況時拋出異常。例如：如果你調用方法Repository.UpdateUser(var user)你期望一個用戶對象，並且它有一個指定的Id（你還可以如何更新它）。

如果不是，你應該拋出異常，因爲沒有遵循方法合約。通過拋出異常，您還會強制開發人員採取措施來防止異常。例如通過確保用戶對象是有效的。

異常畢竟是昂貴的。

並不昂貴。調試沒有進行適當的合理檢查的應用程序可能要花費更多的成本，而不是購買新的硬件來彌補異常性能的下降。 （看到這聽起來很荒謬，因爲異常情況不太可能會影響你的整體表現）。

此外，我需要創造一個例外，相當多的「這可能發生」的情況。

不需要。在調用無法處理這些情況的方法之前，您需要確保處理這些「可能發生的情況」。

所以問題是......你設計「通用返回值」或拋出異常？

通用返回值在大多數情況下毫無價值。一個懶惰的開發者會忽略返回值，可能會引入一個潛伏的bug，這個bug會在以後出現並導致幾個小時的調試。

改爲設計方法來預期錯誤或拋出異常。比較int.TryParse和int.Parse。第一個告訴你它可能會失敗（因爲它正在嘗試），而另一個則希望該值是一個整數（並因此拋出一個異常，因爲它不能按照承諾完成，如果它不是）。