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