servicestack - JsonServiceClient 方法和 IReturn

Question

在我们的团队中，我们使用请求和响应 DTO，通过我们的业务逻辑组件层次结构（在隔离的 DB DTO 之外）。

我们要求在业务逻辑层没有 SS 依赖。

所以我们不使用 IReturn 或 IReturnVoid 接口。我们只使用没有继承的简单 c# 对象。

至于路由，我们在 AppHost.Configure 中使用Fluent API ，本质上是创建一个路由表。

在我们的例子中，ServiceStack 表现得非常好。

我们的 Service.Model 可以从业务逻辑层使用，无需依赖。

服务函数实际上是一个瘦包装器，调用业务逻辑函数，返回响应 DTO。

但是 JsonServiceClient.Get 函数只接受一个 IReturn 对象作为参数，或者直接接受 URI。

它不接受对象作为参数，例如 Post 函数。

有什么建议吗？

更新 1。

神话，

关于 IReturn，不幸的是，在我们的案例中，业务逻辑模块中没有使用需求，

甚至更轻的 SS 依赖。

服务功能是一个调用业务模块的瘦包装器。

两层之间的链接只是请求和响应 DTO。我们非常喜欢这种方法。

是的，它们是“消息操作”，但它们也用作应用层之间的消息。

此外，我的客户主要是 Jquery Ajax，而不是 C#。因为移动，绝大多数倾向于Jquery Ajax。

因此，在我们的例子中，我们只能使用对象，而不是用 IReturn 标记。ServiceStack 表现得非常好。

Answer 1

API 只接受IReturn<TResponse>以明确表示它只接受和使用请求 DTO，而不仅仅是任何 DTO 或对象。请求 DTO 是“消息操作”，不应重复用于其他任何事情，DTO 类型可以，但不是请求 DTO，它是您面向外部的服务合同，不应与任何其他问题耦合。

DTO 属性，如[Route], IReturn<T>, [Api],[Restrict]等只是额外的元数据，不能用 C# 表示，但就像定义 DTO 属性的类型一样，它仍然是描述服务的元数据，如果您将它们归因于 DTO，那么它们也可以在客户端上共享和自省。例如，ServiceClients 将只能使用定义的自定义路由，[Route]因为这是客户端拥有的唯一信息，如果没有，它将最终回退到使用预定义的路由。

ServiceStack 鼓励定义IReturn<T>标记，因为它允许您通过查看请求 DTO 来推断更多关于服务的信息，确保服务被限制返回相同类型（良好实践）并集中服务返回的内容而不是分散在不同的内容上（更详细/ non-DRY) 调用站点，这也意味着如果您更改服务返回的响应，您将获得关于哪些调用站点需要更新的编译器反馈。不是每个人都知道这个信息/行为，这就是为什么 ServiceStack 想要通过鼓励使用IReturn<T>标记来鼓励这个“成功的坑”开发，所以不是每个人都必须这样做。

至于依赖项，您的 DTO 应该需要引用的唯一依赖ServiceStack.Interfaces.dll项是故意为轻量级、无 impl 的 dll。在v3中，这需要引用ServiceStack.Common NuGet pkg，但对于v4，我们将提供独立的ServiceStack.Interfaces NuGet pkg，提供您的 DTO 可以引用的最小/最轻的依赖项。