我们目前正在辩论是否最好在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