我注意到少数 WCF 应用程序选择“分解”它们的对象；也就是说，一个项目可能有一个包含 DataContracts/Members 的 DataObjects 程序集，以及一个执行业务逻辑的有意义的类库。
这是不必要的抽象级别吗？使用 DataContract 信息检查和标记现有类库是否存在任何固有的弊端？
另外，顺便说一句，您如何处理错误情况？服务抛出的异常（InvalidOperation、ArgumentException 等）是否被普遍接受，或者通常有一个与之相关的级别？
【问题讨论】：
标签： wcf
将内部业务对象与数据合同/消息合同分开的关键原因是，您不希望应用的内部更改必然会更改服务合同。如果您正在创建版本化的 Web 服务（具有多个已实现接口的版本），那么您的应用业务对象的单个版本通常具有多个版本的数据合同/消息合同对象。
此外，在复杂的企业集成情况下，您通常拥有由多个应用程序共享的规范数据格式（数据和消息合同），这迫使每个应用程序将规范数据格式映射到其内部对象模型。
如果您想要一个工具来帮助解决分离数据合同/消息合同等问题，请查看 Microsoft 的 Web 服务软件工厂http://msdn.microsoft.com/en-us/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());
如果您想了解更多详细信息，请大喊；我一直在生活和呼吸这些东西很长时间，我几乎以此谋生；）
【讨论】：