本节是翻译整理的WCF服务编程设计规范(8)，内容主要包括：服务托管、自托管代码、客户端代理类、客户端代理管理、客户端异常管理、数据契约、SOAP与REST。如何选择托管类型？，如何管理客户端代理？如何处理客户端异常？如何选择数据契约？如何选择SOAP与REST服务?给出了选择标准。
Service Hosting
服务托管
l Favor WAS Hosting when Server 2008 is an option
可以使用Server2008
的时候，推荐使用WAS
Ø Multiple protocol support IIS Hosting model and tools
多协议支持IIS
托管模型和工具
l Favor IIS for external HTTP only services
对外开放的http
服务推荐使用IIS
Ø Better on-box scalability / availability through worker
通过工作线程能获得更好的扩展性/
可用性
Ø process model
处理模型
Ø Better management tools
更好的管理工具
l Favor self-hosting for stateful services, callbacks, .NET Service Bus, debugging
状态服务、回调、.NET Service Bus
和调试推荐自托管
l Have a console-based debug self-host for development time
开发时使用Console
控制台托管
Ø Can be a Windows Service project that is used for production self-hosting with a mode switch for debugging
可以用于产品阶段托管在Windows
服务的项目类型，利于模型转换与调试
l Consider Dublin hosting in the future
将来考虑Dulbin
托管（Windows Application Server
）
Self Host Code
自托管代码
l Do not put ServiceHost in a using statement in production code
不要是在产品的Using
代码块里使用ServiceHost
Ø Dispose can throw an exception that masks the real
Dispose
可以跑出掩盖事实的异常
Ø Exception thrown from Open call
开放调用跑出的异常
Ø Explicitly call Close in try/catch, log/ deal with exception in catch
在try/catch
里明确调用Close
方法，在Catch
代码里Log
并处理异常
Client Proxy Classes
客户端代理类
l Favor static proxy class over ChannelFactory
在ChannelFactory
上推荐静态代理类
Ø Connection caching in the base class in 3.5
WCF3.5
在基类里支持连接缓存机制
Ø Place for encapsulation of common patterns
封装常用模式的地方
l Hand-code or micro-code generate proxy classes for internal services
为内部服务手动编写代码或者微代码
生成代理类
Ø Less bloated code
避免臃肿的代码
Ø Share service contract and data contracts through libraries
通过类库共享服务和数据契约
Ø Explicit control over config file
通过配置文件明确控制
l Add Service Reference for external services or when you want an async API on the client
为外部服务添加服务引用或者当你想在客户端使用异步API
的时候
Ø Clean up config after it destroys it
当你销毁它的时候，清楚配置
Ø Make sure to add references to data contract libraries before adding the service reference to avoid duplicate definitions
在引用服务之前确保引用数据契约类库，避免代码重复
Ø Live with the duplicate service contract definition instead of needing to repeatedly clean up the proxy code
使用复制的服务契约定义来代替重复的清理代理代码的工作
Client Proxy Management
客户端代理管理
l Cache client proxies if frequent calls to avoid session establishment cost
如果调用频繁，使用代理缓存，避免建立会话代价
Ø If secure / reliable session enabled
如果启用安全/
可靠的会话
Ø Have to deal more cautiously with faulted proxies
特别注意处理错误的客户端代理
u Check proxy state before using
使用之前检查代理的状态
u Get rid of proxy after exception
异常以后清除代理
l Don’t put proxies in a using statement
不要把代理放到一个using
代码块中
Ø Dispose call might throw exception and mask real exception
销毁调用可能抛出异常并掩盖真实的异常
Ø Explicitly close in a try/catch block, and if Close throws an exception, abort the proxy to ensure resource clean up
在try/catch
块里，清晰地关闭，并且，如果close
的时候抛出异常，终止代理确保资源释放
Client Exception Management
客户端异常管理
l All exceptions thrown from a service call derive from CommunicationException
所有的调用服务的异常都继承自CommunicationException
l FaultException could be wrapped unhandled exception on the client, or explicit error returned from the service
FaultException
可以被包装在一个客户端的未处理异常中，或者明确返回自服务
l FaultException<T> always an explicit error returned from the service
FaultException<T>
始终明确从服务返回的错误
l Simple approach:
简单的方法
Ø Any exception from a proxy call, safe close the proxy
代理调用时发生任何异常，都要安全地关闭代理
l Advanced approach:
高级方法
Ø FaultException<T> - proxy is reusable
FaultException<T>-
代理是可以复用的
Data Contracts
数据契约
l Favor data contracts over serializable types
推荐使用可序列化类型作为数据契约
Ø More explicit model, better control over what the client sees
更清晰的模型，对于客户端说看到的数据进行更好的控制
l Implement IExtensibleDataObject
实现IExtensibleDataObject
接口
Ø Avoids dropping data that the service / client does not understand
避免使用服务/
客户端都不明白的数据
l Avoid passing complex .NET specific types for interoperable services
避免在互操作服务里传递复杂的.NET
类型
Ø DataSets and Exception types
DataSets
和 Exception
类型
l Avoid XmlSerializer and MessageContracts except for interoperable scenarios and REST services
除了互操作的场景和REST
服务，避免XmlSerializer
（XML
序列化器）和MessageContracts
（消息契约）
SOAP vs. REST
SOAP与REST
l Favor SOAP services when you are writing a service that only your code will consume
当你编写的服务只有你自己使用时，推荐SOAP
l Favor REST services for publicly exposed, data oriented services
当你的服务是公开暴露、面向数据时，推荐使用REST
本文转自 frankxulei 51CTO博客，原文链接：http://blog.51cto.com/frankxulei/320878
，如需转载请自行联系原作者
