在我们的团队中，我们通过业务逻辑程序集的层次结构（超出隔离的DB DTO）使用请求和响应DTO。
我们要求业务逻辑层不存在SS依赖关系。
因此我们不使用IReturn或IReturnVoid接口。我们只使用没有继承的简单c＃对象。
对于路由，我们在AppHost.Configure中使用Fluent API，基本上创建了一个路由表。
在我们的案例中，ServiceStack行为非常好。
我们的Service.Model可以在业务逻辑层使用，没有依赖关系。
服务函数实际上是一个瘦包装器，调用业务逻辑函数，返回响应DTO。
但是JsonServiceClient.Get函数仅接受IReturn对象的参数，或者直接接受URI。
它不接受对象作为参数，如Post函数。
有什么建议吗？
更新1 。
mythz ，
关于IReturn，遗憾的是，在我们的案例中，有些要求没有在业务逻辑模块中使用，
即使是较轻的SS依赖。
服务功能是一个调用业务模块的瘦包装器。
两个层之间的链接只是请求和响应DTO。我们非常喜欢这种方法。
是的，它们是“消息操作”，但它们也充当应用程序层之间的消息。
我的客户主要是Jquery Ajax，而不是C＃。由于移动设备，绝大多数都倾向于Jquery Ajax。
因此，在我们的例子中，我们只能使用未标记为IReturn的对象。 ServiceStack行为非常好。
答案 0 :(得分：1)
API仅接受IReturn<TResponse>以明确表示它只接受并使用Request DTO，而不仅仅是任何DTO或对象。请求DTO是“消息操作”，不应该重复用于其他任何事情，DTO类型可以是，但不是请求DTO，它是您的external facing service contract，不应该与任何其他问题相关联。
像[Route]，IReturn<T>，[Api]，[Restrict]等DTO属性只是无法用C＃表达的额外元数据，但就像定义DTO属性的类型，它仍然是描述服务的元数据，如果你将它们归因于DTO，那么它们在客户端上也变得可共享和内省。例如。 ServiceClients只能使用[Route]定义的自定义路由，因为这是客户端拥有的唯一信息，如果没有，它将最终回退到使用预定义的路由。
ServiceStack鼓励定义IReturn<T>标记，因为它可以通过浏览Request DTO来确定服务的更多信息，确保服务在返回相同类型（良好实践）时受到限制，并集中化服务返回而不是传播在不同的（更详细/非DRY）呼叫站点上，这也意味着如果您更改响应服务返回，您将获得有关哪些呼叫站点需要更新的编译器反馈。并非所有人都知道这些信息/行为，这就是为什么ServiceStack希望通过鼓励使用IReturn<T>标记来鼓励这种“成功之道”，所以不是每个人都必须这样做。
至于依赖关系，你的DTO应该引用的唯一依赖是ServiceStack.Interfaces.dll，这是一个特别轻量级，无impl的dll。在 v3 中，这需要引用 ServiceStack.Common NuGet pkg，但对于 v4 ，我们将提供独立的 ServiceStack.Interfaces NuGet pkg提供DTO可以参考的最小/最轻的依赖。