WCF服務編程設計規範(8):服務託管、自託管代碼、客戶端代理管理

本節是翻譯整理的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