WCF 作為面向服務架構 (SOA) 的實現框架，其核心特徵是服務與客戶端之間的鬆散耦合與明確邊界。這與傳統物件導向 (OO) 設計中強調的繼承多型、依賴倒置 (DIP)、里氏替換原則 (LSP) 形成了深層張力。本文將透過「手機/MP3/錄音機」與「訂單/訂單明細」兩個經典案例，深度剖析 WCF 在服務契約繼承扁平化與資料契約跨邊界繼承失效上的機制與設計哲學。
WCF 通訊雙方 (服務端/客戶端) 存在明確的**序列化/反序列化邊界**。即使使用 NetNamedPipeBinding (進程內)，邏輯邊界依然存在。代理類 (Proxy) 扮演「媒人」角色，**只傳遞契約 (Schema)，不傳遞實作邏輯與型別層次**。這決定了：
[ServiceContract] public interface IMp3 { [OperationContract] void PlaySound(string file); }
[ServiceContract] public interface IRecorder { [OperationContract] void Record(); }
[ServiceContract] public interface ITelephone : IMp3, IRecorder // 繼承關係
{
[OperationContract] void Call(string to);
[OperationContract] void Pickup(string from);
// ...
}
public class Telephone : ITelephone { /* 實作所有方法 */ }
服務端以單一類別 Telephone 實作完整介面層次，並暴露三個端點：
host.AddServiceEndpoint(typeof(IMp3), binding, "mp3");
host.AddServiceEndpoint(typeof(IRecorder), binding, "recorder");
host.AddServiceEndpoint(typeof(ITelephone), binding, "tel");
執行 svcutil.exe 產生的 Proxy.cs 中：
IMp3、IRecorder、ITelephone **變成三個獨立介面，無繼承關係**ITelephone **內聯** 了 PlaySound、Record 等方法定義Mp3Client、RecorderClient、TelephoneClientIMp3 + Mp3Client，完全不知道 IRecorder/ITelephone 存在[DataContract]
public class Order
{
[DataMember] public string OrderName { get; set; }
}
[ServiceContract]
public interface IOrderManager
{
[OperationContract] void Process(Order order);
}
// 客戶端自行定義衍生類別
[DataContract(Name="OrderDetail")] // 名稱不同！
public class OrderDetail : Order
{
[DataMember] public DateTime CreateTime { get; set; }
}
// 調用
var proxy = new OrderManagerClient();
proxy.Process(new Order()); // 成功
proxy.Process(new OrderDetail()); // 拋出異常！
WCF 預設使用 DataContractSerializer，反序列化時**嚴格比對 XML 名稱/命名空間 與已知型別清單**。OrderDetail 雖繼承 Order，但：
OrderDetail vs Order)OrderDetail 存在，未加入 KnownType<OrderDetail>，不符合預期的 <Order>結論：里氏替換原則 (LSP) 在 WCF 服務邊界失效。子類別無法透明替換基類別跨邊界傳遞。
[KnownType(typeof(OrderDetail))] 標註於服務端基底類別或操作合約[ServiceKnownType("GetKnownTypes")] 動態提供已知型別IExtensibleDataObject 保留未知資料 (向前相容)，但**不解決多型傳遞**| OO 原則 | 傳統意義 | WCF/SOA 實踐 | 核心差異 |
|---|---|---|---|
| 依賴倒置 (DIP) | 高層模組依賴抽象介面，實作依賴抽象 | 雙方依賴**共享契約 (Schema/Interface)**，而非共享組件/繼承體系 | 契約 = 抽象，但跨越進程/機器邊界 |
| 里氏替換 (LSP) | 子類別必須能透明替換基類別 | **跨邊界不成立**；僅在同一進程共享組件時成立 | 序列化打破多型，需顯式 KnownType 協助 |
| 介面隔離 (ISP) | 介面應細小專一 | **天然滿足**：Proxy 扁平化拆分介面，客戶端按需引用 | SOA 強化了 ISP |
IExtensibleDataObject 或新增選擇性 DataMemberWCF 的「OO 大背離」並非缺陷，而是 **SOA 邊界特性的必然結果**。服務契約扁平化踐行了介面隔離原則；資料契約跨邊界繼承失效提醒我們：**序列化邊界切斷了多型**。理解這一點，您將不再試圖在分散式系統中強行套用單體應用的繼承模式，而是擁抱**契約優先、組合大於繼承、版本容錯**的服務設計哲學，構建真正可演進、鬆散耦合的分散式系統。
