8

我们正在考虑在下一个项目中使用 ServiceStack；在查看示例时，我注意到没有通用的命名约定。 例如：

实体：电影
请求：电影
响应：MovieResponse

所有操作也是如此。 现在这个例子：

实体：回答
请求：回答
回答：AnswerResult

完后还有：

实体：用户？
请求：GetUsers
响应：GetUsersResponse

（看到类名以动词开头有点奇怪）

所以，也许你想出了一些聪明的命名约定并想分享。此外，在服务堆栈上是否有任何更大的开源项目，我可以在其中查看他们如何组织他们的服务模型？

4

2 回答 2

13

我使用具有以下样式的BREAD 1和动词实体：

命名空间是“实体”，那么：

  • 浏览实体
  • 浏览实体响应
  • 浏览实体服务
  • 添加实体
  • 添加实体响应
  • 添加实体服务

请注意，表单实际上是 [Verb][Entity][Role]。

  • 动词：浏览、阅读、编辑、添加、删除（面包）、验证、提取（例如其他操作）

  • 实体：这是复数或单数，取决于受影响/检索到的实体的正常数量。（我并不完全否认像 DeleteEntity 这样的服务可能一次删除多个实体，但如果放入“单数”名称的 DTO/服务中，则应仔细考虑。它总是可以跟随复数 DeleteEntities。）

  • 作用：（无）=请求DTO，响应=响应DTO，服务=服务。

  • 命名空间：总是复数。这避免了与实体（单数）等 DAL 类的冲突。

对于 BREAD 绑定（端点总是复数，它代表一个集合）：

  • /entities GET - 浏览实体
  • /entities/Id GET - 读取实体
  • /entities/Id POST - EditEntity（不在 PUT 上出售；尚未研究 PATCH 支持）
  • /entities POST - 添加实体
  • /entities/Id DELETE - DeleteEntity

杂项。约束准则：

  • /entities/Id/verb POST/GET - VerbEntity（即 ValidateEntity），仅在幂等时获取。
  • /entities/_/verb POST/GET - VerbEntitiy，适用于没有资源标识的任意（但特定）实体。这很少见，但用于验证尚未保存的实体等情况。它允许模式保持一致。
  • /entities/verb POST/GET - VerbEntities，适用于集合，但不适用于任何特定资源。
  • /entities/Id/items/.. - 一个子/相关端点，与具有给定 ID 的实体相关。遵循前面讨论的相同模式。

1不幸的是，BREAD 似乎是一个边缘术语。来自CRUD 维基百科文章：

CRUD 的另一个变体是 BREAD，它是“浏览、阅读、编辑、添加、删除”的首字母缩写词。

我更喜欢它的声音，并且它有一个单独的浏览操作。

于 2013-02-28T07:20:54.577 回答
4

我目前使用第三个选项，请求以动词开头。原因是我的实现并不完全基于典型的 REST 样式 url，而且我广泛使用 c# 客户端。在这种情况下，动词只是有助于清楚地识别服务的目的。

除了我的特殊情况，我会去

实体：电影请求：电影响应：MovieResponse

于 2013-02-08T10:14:20.590 回答