ServiceStack：真的是“简洁优雅的设计”吗？答案

【问题标题】：ServiceStack: is really "Simple and Elegant Design"?ServiceStack：真的是“简洁优雅的设计”吗？
【发布时间】：2013-06-04 15:38:59
【问题描述】：

大家！

我最近尝试使用 ServiceStack 框架，但遇到以下不清楚。

我可以或我不能对那个库执行以下操作：

public class userService : Service
{
    public object Get(int? userId)
    {
        // instead of receiving user request object (empty or filled only with its id property)
        return new userResponse();
    }
}

对我来说，整个 DTO/请求/响应类逻辑的另一件事很奇怪，即我应该定义三个类，它们以相似的名称（例如“用户”）开头，另外，处理 DTO 的服务是由参数（！）（获取（用户请求））找到。我对吗？或者这只是因为我没有完全理解ServiceStack的逻辑？如果是这样，那就太不方便了。当在 DTO(!) 上定义服务端点（服务操作）但最初没有定义服务类时，这看起来很奇怪。有没有可能以任何方式做这样的事情？：

[Route("/users")]
public class userService : Service
{
    public object Get()
    {
        return new ResponseBase(new List<Users>());
    }
    public object Get(int id)
    {
        return new ResponseBase(new User());
    }
}

这看起来主要是一个 ASP.NET Web API。然而，随即出现一个问题。为什么使用 ServiceStack？只是因为它是更早创建的吗？

谢谢！

【问题讨论】：

标签： asp.net json web-services rest servicestack

【解决方案1】：

您正在尝试将 ServiceStack 用作控制器，而不是用作它旨在支持的 DTO-first message-based 服务。如果您想使用 RPC 方法签名来创建服务，我建议您返回使用支持此开发模型的 WCF、MVC 或 WebApi。

如果您还想继续使用 ServiceStack，我建议您花一些时间阅读Getting Started documentation，而不是猜测它是如何工作的。

主页上的Simple REST Service 准确地展示了如何创建一个简单的服务，就像您要创建的服务一样。如需进一步了解如何设计服务，请参阅：

【讨论】：

感谢您的回答。实际上，我确实阅读了“入门”文档，并且确实看到了那个 cs 文件示例。实际上，这主要是问这个问题的一个原因。当系统根据调用方法参数确定要调用哪个服务类时，逻辑对我来说有点奇怪。我问这个是因为因为它对我来说看起来很奇怪，这意味着要么我在该地区没有得到任何东西，要么......“它是在一段时间前以这种方式实现的，因为它-以这种方式实施”。所以，如果是这样，我有一个答案。 :)
支持 DTO 优先、基于消息的设计是有意不同的。它是designed to change how you approach web service development，也就是说，它不想考虑调用远程服务器方法签名，而是希望您考虑向远程实例发送消息 - 将请求与实现分离。