我們目前正在辯論是否最好在WCF通道上拋出錯誤,而不是傳遞指示服務狀態或響應的消息。WCF - 故障/異常與消息
故障來自WCF的內置支持,您可以使用內置的錯誤處理程序並作出相應的反應。然而,這會帶來開銷,因爲在.NET中拋出異常可能會非常昂貴。
消息可以包含必要的信息,以確定發生了什麼事與您的服務調用沒有拋出異常的開銷。但是,它需要幾行重複代碼來分析消息並確定其內容後面的操作。
我們帶着刺創造,我們可以在我們的服務採用一個通用的消息對象,而這也正是我們提出了:
public class ReturnItemDTO<T>
{
[DataMember]
public bool Success { get; set; }
[DataMember]
public string ErrorMessage { get; set; }
[DataMember]
public T Item { get; set; }
}
如果我所有的服務調用返回這個項目,我可以持續檢查「成功」屬性來確定是否一切順利。然後我在事件中顯示錯誤消息字符串,表明出現了錯誤,並且如果需要,則會包含Dto的通用項目。
必須將異常信息記錄到中央日誌記錄服務,而不是從服務傳回。
想法?註釋?想法?建議?
一些進一步澄清我的問題
一個問題我在遇到故障時合同的通信業務規則。
像,如果有人登錄,並且他們的帳戶被鎖定,我該如何溝通?他們的登錄顯然失敗,但由於「賬戶鎖定」原因而失敗。
所以做我:
A)使用一個布爾值,拋出故障與消息帳戶鎖定
B)相關信息
我不同意。由於WCF應該是語言不可知的(至少在某種形式中),你不能保證在線路上傳遞一個Exception對象不會導致buig問題。 Java客戶端。 FaultContract對象類型可以確保互操作性,因爲它是OASIS規範的一部分。 – ZombieSheep 2008-09-17 09:39:40