將wcf服務合同與接口定義分開是否有任何價值？

Question

我有一個接口ICustomerService：

public interface ICustomerService
{

  CustomerList FindAll();
}

以及實現該接口的具體類。 現在，我需要使用wcf / rest在Web上公開該方法，並且不得不將接口定義更改為：

[ServiceContract]
public interface ICustomerService
{
  [OperationContract]
  [WebInvoke(
   Method = "GET",
   UriTemplate = "Customers")]
  CustomerList FindAll();
}

我的問題是，如果有客戶端想要使用通過dll引用而不是使用其余api的實現，則將這些屬性附加到您的接口是否有不利影響？ 我知道使用REST的缺點，例如如果在uri中必須將參數設置為類型字符串。

Answer 1

該屬性應該沒有缺點，除非代碼可讀性強（如果您的客戶端必須查看您的界面源）。

感興趣的任何人（例如WCF框架）都可以讀取該屬性，或者將其忽略。 實際上，它們在任何實現類中都不可見（請參閱此問題 ）。

但是，在體系結構級別，請考慮使用2個接口，一個用於dll引用客戶端，一個用於REST客戶端。 一開始它們可能很相似，它們甚至可能共享相同的基本接口和實現，但是如果業務案例需要，您可以使它們彼此轉移。
同樣，這使您可以在WCF Web應用程序項目中保留WCF屬性填充的接口，並在核心類庫項目中保留干凈的接口和實現。