爲什麼界面IHasResponseStatus使用ServiceStack類？

接口IHasResponseStatus強制您實現ServiceStack類。爲什麼界面IHasResponseStatus使用ServiceStack類？

爲什麼ResponseStatus不是另一個接口而不是一個類？

現在實現接口IHasResponseStatus是「不可能的」，因爲它與ServiceStack類是一對一的。

namespace ServiceStack.ServiceInterface.ServiceModel 
{ 
/// 
/// Contract indication that the Response DTO has a ResponseStatus 
/// 
public interface IHasResponseStatus 
{ 
ResponseStatus ResponseStatus { get; set; } 
} 
}

來源

2013-06-27 Svein Helge

你不會被迫使用IHasResponseStatus，它只是讓你知道正確的簽名是什麼，如果你想擁有包括你的DTO ResponseStatus。

即使那麼你就不會被迫包括ResponseStatus你的DTO作爲New API讓你回到乾淨的反應，其中任何異常的通用ErrorResponse DTO中獲得序列化。閱讀docs on Error Handling瞭解更多信息。

除了interfaces being a terrible idea to have on DTO's以外，它是ServiceStack中的一個具體類，因此它可以應用XML和SOAP序列化程序和端點所需的程序集範圍XML名稱空間DataContract聲明。

來源

2013-06-27 17:34:29 mythz

部隊並不是單詞的最佳選擇。我的觀點是，在接口中擁有自己的類並不是一個好主意（恕我直言），因爲具有接口的點是其他（或者你自己）擁有自己的類來實現接口的能力。 –

接口只增加跨進程邊界的耦合（它只是在代碼中減少），因爲消費者不知道要反序列化的具體類型，所以它必須發出序列化特定的實現提示，現在在線上嵌入了C＃問題（所以現在甚至C＃命名空間會破壞序列化），現在限制了你的響應被特定的序列化器使用。它也不會讓你指定在XML/SOAP中使用的xmlns。 – mythz

通常，與接口和自己的類建立一對一的關係並不是一個好主意。這種情況可能是一個例外，因爲你想要一個通用的響應對象，在那裏你可以控制XML名稱空間，並且使用抽象類繼承並不是最好的想法，因爲c＃不支持來自多個類的繼承，並且DTO上的繼承不是如前所述，這是最好的想法。我明白爲什麼選擇這種方法。謝謝你的好解釋。 –

爲什麼界面IHasResponseStatus使用ServiceStack類？

回答

相關問題