Service Hosting
服务托管
lFavor WAS Hosting when Server 2008 is an option
可以使用Server2008
的时候，推荐使用WAS
ØMultiple protocol support IIS Hosting model and tools
多协议支持IIS
托管模型和工具
lFavor IIS for external HTTP only services
对外开放的http
服务推荐使用IIS
ØBetter on-Box scalability / availability through worker
通过工作线程能获得更好的扩展性/
可用性
Øprocess model
处理模型
ØBetter management tools
更好的管理工具
lFavor self-hosting for stateful services,callbacks,.NET Service Bus,debugging
状态服务、回调、.NET Service Bus
和调试推荐自托管
lHave 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
服务的项目类型，利于模型转换与调试
lConsider Dublin hosting in the future
将来考虑Dulbin
托管（Windows Application Server
）
Self Host Code
自托管代码
lDo 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
Client Proxy Classes
客户端代理类
lFavor static proxy class over ChannelFactory
在ChannelFactory
上推荐静态代理类
ØConnection caching in the base class in 3.5
WCF3.5
在基类里支持连接缓存机制
ØPlace for encapsulation of common patterns
封装常用模式的地方
lHand-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
通过配置文件明确控制
lAdd 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
客户端代理管理
lCache client proxies if frequent calls to avoid session establishment cost
如果调用频繁，使用代理缓存，避免建立会话代价
ØIf secure / reliable session enabled
如果启用安全/
可靠的会话
ØHave to deal more cautIoUsly with faulted proxies
特别注意处理错误的客户端代理
uCheck proxy state before using
使用之前检查代理的状态
uGet rid of proxy after exception
异常以后清除代理
lDon’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
Client Exception Management
客户端异常管理
lAll exceptions thrown from a service call derive from CommunicationException
所有的调用服务的异常都继承自CommunicationException
lFaultException could be wrapped unhandled exception on the client,or explicit error returned from the service
FaultException
可以被包装在一个客户端的未处理异常中，或者明确返回自服务
lFaultException<T> always an explicit error returned from the service
FaultException<T>
始终明确从服务返回的错误
lSimple approach:
简单的方法
ØAny exception from a proxy call,safe close the proxy
lAdvanced approach:
高级方法
ØFaultException<T> - proxy is reusable
FaultException<T>-
代理是可以复用的
Data Contracts
数据契约
lFavor data contracts over serializable types
推荐使用可序列化类型作为数据契约
ØMore explicit model,better control over what the client sees
更清晰的模型，对于客户端说看到的数据进行更好的控制
lImplement IExtensibleDataObject
实现IExtensibleDataObject
接口
ØAvoids dropping data that the service / client does not understand
避免使用服务/
客户端都不明白的数据
lAvoid passing complex .NET specific types for interoperable services
避免在互操作服务里传递复杂的.NET
类型
ØDataSets and Exception types
DataSets
和 Exception
类型
lAvoid XmlSerializer and MessageContracts except for interoperable scenarios and REST services
除了互操作的场景和REST
服务，避免XmlSerializer
（XML
序列化器）和MessageContracts
（消息契约）
SOAP vs. REST
SOAP与REST
lFavor SOAP services when you are writing a service that only your code will consume
当你编写的服务只有你自己使用时，推荐SOAP
lFavor REST services for publicly exposed,data oriented services
当你的服务是公开暴露、面向数据时，推荐使用REST
原文链接：https://www.f2er.com/javaschema/287574.html