为什么界面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类？

回答

相关问题