我注意到，少数WCF应用程序选择将它们的对象"分解"。也就是说，一个项目可能具有一个DataObjects程序集，该程序集除了执行业务逻辑的有意义的类库外，还包含DataContracts / Members。

这是不必要的抽象级别吗？通过DataContract信息遍历和标记现有类库是否有任何固有的弊端？

此外，顺便说一句，我们如何处理错误情况？是否通常接受服务中引发的异常(InvalidOperation，ArgumentException等)，或者通常围绕该异常进行处理？

解决方案

回答

将内部业务对象与数据合同/消息合同分开的主要原因是，我们不希望对应用程序进行内部更改而必须更改服务合同。如果要创建版本化的Web服务(已实现的接口的版本不止1个)，则应用程序业务对象通常只有一个版本，而数据合同/消息合同对象的版本则不止1个。

另外，在复杂的企业集成情况下，我们通常具有规范的数据格式(数据和消息合同)，该格式由许多应用程序共享，这迫使每个应用程序将规范的数据格式映射到其内部对象模型。

如果我们想要一个工具来帮助分离数据合同/消息合同等，请访问Microsoft的Web服务软件工厂http://msdn.microsoft.com/zh-cn/library/cc487895.aspx，其中包含一些内容解决WCF管道的好方法。

关于特权，WCF自动将所有异常包装在FaultExceptions中，这些异常被序列化为有线格式故障。

也有可能引发通用的"故障异常"，这使我们可以指定要包含在序列化故障中的其他详细信息。由于Web服务操作引发的错误是其合同的一部分，因此最好在操作声明中声明错误：

[FaultContract(typeof(AuthenticationFault))]
[FaultContract(typeof(AuthorizationFault))]
StoreLocationResponse StoreLocation(StoreLocationRequest request);

AuthenticationFault和AuthorizationFault类型都表示要序列化并通过网络发送的其他详细信息，可以按以下方式引发：

throw new FaultException<AuthenticationFault>(new AuthenticationFault());

如果我们想了解更多细节，请大喊大叫；我一直在生活和呼吸这些东西很久了，我几乎以谋生为生;)