WCF 服務合約繼承與分解設計：介面隔離與契約因子化實務

服務合約設計直接決定系統的耦合度、可重用性與演進彈性。WCF 合約本質為 .NET 介面加上屬性，但 ServiceContractAttribute 不支援繼承 (Inherited = false)，導致合約層級設計有特殊限制。

合約繼承的限制與對策

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Interface, Inherited = false)]
public sealed class ServiceContractAttribute : Attribute { }

規則：每一層介面皆須標註 [ServiceContract]，否則該層作業合約不會被公開。

[ServiceContract(Namespace = "https://ns")]
public interface IVehicle { [OperationContract] string Run(); }

[ServiceContract(Namespace = "https://ns")]
public interface ITruck : IVehicle { [OperationContract] string Carry(); }

[ServiceContract(Namespace = "https://ns")]
public interface ICar : IVehicle { [OperationContract] string Take(); }

宿主端點繫結至最底層介面 (ITruck)，單一端點暴露完整作業集 (Run + Carry)。

客戶端 Proxy 扁平化問題

匯入中繼資料時，繼承階層會被扁平化：產生單一介面 ITruck 包含所有作業 (Run, Carry)，失去原始階層。
對策：手動調整 Proxy 程式碼恢復階層，或接受扁平化 (單一介面) 簡化呼叫。

服務合約分解原則 (Contract Factoring)

遵循 SOLID 原則：

• SRP (單一職責)：一個合約只負責一個業務領域。
• ISP (介面隔離)：客戶不應依賴不使用的作業。拒絕「胖介面」 (如同時包含 Run、Take、Carry 的 IVehicle)。
• 平衡介面粒度：過細 → 整合成本高；過粗 → 實作與維護困難。經驗值：單一合約 3-5 個作業，上限 20。

分解範例：交通工具領域

反模式：單一 IVehicle 包含 Run、Take、Carry → 強迫貨車實作 Take、轎車實作 Carry。

正確分解：

[ServiceContract] interface IVehicle { [OperationContract] string Run(); }
[ServiceContract] interface ITruck : IVehicle { [OperationContract] string Carry(); }
[ServiceContract] interface ICar : IVehicle { [OperationContract] string Take(); }

• 貨車服務實作 ITruck (Run + Carry)。
• 轎車服務實作 ICar (Run + Take)。
• 共用邏輯 (Run) 集中於基介面，避免重複。

避免屬性式作業

勿設計：[OperationContract] string GetCarNumber(); (類似 Property Getter)。
服務應封裝狀態管理，客戶端呼叫行為導向作業 (如 RegisterVehicle)，而非存取屬性。

總結

WCF 合約設計需兼顧 伺服端繼承限制 (每層加 ServiceContract)、客戶端扁平化現實 與 SOA 設計原則 (SRP/ISP/粒度平衡)。合理分解合約、控制作業數量、避免屬性式作業，是打造可維護、可演進服務介面的關鍵。