3

我开始使用 ServiceStack 来实现 Web 服务 API。我正在尝试尽可能多地遵循示例和最佳实践，但有时这并不容易（似乎许多示例尚未更新以遵循新的 API 设计）。

我目前拥有的是这样的：

  • 一个名为MyApp.ServiceInterface包含服务/方法实现的程序集
  • MyApp.ServiceModel包含请求和响应类型以及 DTO的程序集

在MyApp.ServiceModel大会中，我有例如：

namespace MyApp.ServiceModel
{
    public abstract class ResponseBase
    {
        public ResponseStatus ResponseStatus { get; set; } // for error handling
    }

    [Route("/products/{Id}")]   // GET: products/123
    [Route("/products")]        // GET: products?Name=...
    public class ProductRequest : IReturn<ProductResponse>
    {
        public int Id { get; set; }
        public string Name { get; set; }
    }

    public class ProductResponse : ResponseBase
    {
        public Types.Product Product { get; set; }
    }
}

namespace MyApp.ServiceModel.Types
{
    public class Product
    {
        public int Id { get; set; }
        public string Name { get; set; }
        // ...
    }
}

问题：

  • 我已经看到了如何命名请求类型的不同方法（例如GetProduct，ProductRequest或只是Product）。推荐的方法是什么？
  • 命名是否取决于服务是否为 REST 服务？
  • 将请求和响应类型放入单独的（子）命名空间（例如MyApp.ServiceModel.Requests和MyApp.ServiceModel.Responses）是否是个好主意？
  • 为什么包含命名的实现的程序集ServiceInterface（不ServiceImplementation适合更好）？
4

1 回答 1

3

API 设计是主观的，因此没有推荐的方法。尽管我个人不喜欢在我的请求 DTO 上附加“请求”后缀，因为它实际上是您的 Web 服务合同。我也不喜欢在服务模型中使用继承来尝试 DRY 属性，这些属性在你的服务层中隐藏了意图，这是你最重要的合同。

请求 DTO 的名称不会影响具有自定义路由的 REST API，因为使用相同自定义路由的不同请求 DTO 没有外部可见的差异。尽管在使用端到端类型化客户端时它确实会影响表面区域，因为它构成了类型化 API 的可见部分。

这里有几个答案描述了我对如何设计服务 API 的偏好：

DTO 中的 C# 命名空间对您的 API 没有明显影响。在 ServiceStack 请求 DTO 与您的服务 1:1 映射，因此它们必须是唯一的，如果您为响应 DTO 附加“响应”后缀，它们最终也将是唯一的。作为一个目标，我确保我的所有 DTO，包括操作和类型，都是唯一命名的，因此它们的物理布局是什么并不重要。作为惯例，我现在喜欢将我的操作 DTO（即请求/响应）放在服务模型程序集的顶层，请求/响应 DTO 在同一个 C# .cs 文件中，而所有其他“DTO 类型”在一个类型文件夹，例如：

  • /Products.cs（包含 GetProduct 和 ProductResponse DTO）
  • /类型/产品.cs

它被称为服务接口，因为它与网关服务模式相匹配，您的客户端称为客户端网关，而您的服务器称为服务接口。这里的使用是Interface指服务入口点，而不是 C# 接口。

于 2013-06-20T15:29:12.860 回答