2011-04-21 81 views
2

我目前正在向JSF/Richfaces應用程序添加功能,現在我們正在與外部Web服務集成。處理Web服務錯誤代碼(除了一般soapfaultexceptions)

完成的服務操作包括:獲取用戶,獲取帳戶,更新用戶,更新帳戶,創建用戶,創建帳戶。

這些服務以及意外的soapfaultexceptions可以在其響應類型中返回錯誤代碼。主要表現爲沿線的失敗:登錄已經存在,密碼不符合標準,賬號已經存在,並沒有用戶發現。

調用如下所示:BackingBean> Manager級別類(主要是傳遞)> Web服務客戶端(進行實際的WS調用)。對於GET操作,傳遞ID(用戶名或帳號)並將帳戶或用戶對象傳回。更新傳遞用戶/帳戶對象,與Creates相同。

將這些錯誤備份到backingbean的最佳方式是什麼,以便我可以通過UI處理它們?

  1. 當然,我可以檢查響應中的錯誤代碼,拋出一個異常,並繼續將它扔到後臺bean,我將在那裏處理它。
  2. 我可以實現,將舉行一個錯誤類型,而我是從服務填充POJO/DTO結果類型。
  3. 我的一位同事建議我使用裝飾器來裝飾我的USER或ACCOUNT對象,並使用我也需要創建的驗證器。基本上,我想我會裝飾只是抱着自定義錯誤類型和驗證()將只檢查是否(名單!= NULL & &!(面積> 0))。正確?

您對所提議的方法有什麼想法? #1是最容易的,#2似乎是更優雅,還是簡單的,#3是因爲我從來沒有使用Decorator模式的「最艱難」給我。然而,#3似乎是最優雅的,同時也是最耗時的實現。

讓我知道你是否需要更多的解釋。

謝謝,SO!

回答

1

總是最好以編程方式使用例外進行限制(When to throw an exception)。

首先問自己這是一種特殊情況嗎?在你的情況下,它不僅僅是一個驗證錯誤。例外情況會帶來成本,並且不能保證您能夠在鏈下進一步發現異常情況。

2/3都是類似的解決方案,您只是試圖將附加信息返回給控制器。

選3,可考慮更清潔,但如果你有訪問用戶/帳戶類,你總是可以附加屬性添加到可能包含驗證錯誤的類。

此模式的一個很好的例子是ActiveRecord內紅寶石,相同類型的模型。您可以調用保存模型對象,如果發生錯誤,它會填充錯誤屬性。

0

拋出自定義異常或一組自定義異常中的一個,並在較高級別處理它。這是在Java中處理它與狀態代碼我的首選方式,一切都是按值傳遞,並騰出其他目的的返回變量。關於「繼續投擲」,不要在每個關卡都抓到並重新投擲,而只能抓住你可以做些什麼的級別。在這種情況下支持bean/UI。

+0

我傾向於@Nix同意你的錯誤情況,如未能創建一個用戶,因爲帳戶已存在,都不是真正意義的「例外」。 – 2011-04-21 16:43:30