8

次のプロジェクトで ServiceStack を使用することを考えています。例を見ていると、一般的な命名規則がないことに気付きました。 例えば：

エンティティ: ムービー
リクエスト: ムービー
レスポンス: MovieResponse

すべての操作について同じことが言えます。 今この例：

エンティティ: 回答
要求: 回答
応答: AnswerResult

さらに別の:

エンティティ: ユーザー?
リクエスト: GetUsers
レスポンス: GetUsersResponse

(クラス名が動詞で始まっているのを見るのはちょっと変です)

それで、あなたは巧妙な命名規則を思いついたので、共有したいと思うかもしれません. また、サービス スタックに関するより大きなオープン ソース プロジェクトはありますか?

4

2 に答える 2

13

私はBREAD1とVerb - Entityを次のスタイルで使用しています。

名前空間は「エンティティ」であり、次のようになります。

  • BrowserEntities
  • BrowserEntitiesResponse
  • BrowserEntitiesService
  • AddEntity
  • AddEntityResponse
  • AddEntityService

フォームは実際には[動詞][エンティティ][役割]であることに注意してください。

  • 動詞：参照、読み取り、編集、追加、削除（BREAD）、検証、抽出（他の操作など）

  • エンティティ：これは、影響を受ける/取得されるエンティティの通常の数に応じて、複数形または単数形になります。（DeleteEntityのようなサービスが一度に複数のエンティティを削除する可能性があることを完全に軽視しているわけではありませんが、「単一の」名前のDTO /サービスに入れる場合は慎重に検討する必要があります。常に複数のDeleteEntitiesに従うことができます。）

  • 役割:(なし）=要求DTO、応答=応答DTO、サービス=サービス。

  • 名前空間：常に複数形。これにより、Entity（単数）などのDALクラスとの競合が回避されます。

BREADバインディングの場合（エンドポイントは常に複数形であり、コレクションを表します）：

  • / entity GET-BrowseEntities
  • / entity / IdGET-ReadEntitiy
  • / entity / Id POST-EditEntity（PUTでは販売されていません。PATCHサポートを調べていません）
  • / entity POST-AddEntitity
  • / entity / IdDELETE-DeleteEntity

その他 拘束力のあるガイドライン：

  • / entity / Id / verb POST / GET-VerbEntity（つまり、ValidateEntity）、べき等の場合にのみGETします。
  • / entity / _ / verb POST / GET-VerbEntitiyは、リソースが識別されていない任意の（ただし特定の）エンティティに適用されます。これはまれですが、まだ保存されていないエンティティの検証などの場合に使用されます。それ以外の場合はパターンの一貫性を保つことができます。
  • / entity / verb POST / GET-VerbEntitiesはコレクションに適用されますが、特定のリソースには適用されません。
  • / entity / Id / items/..-指定されたIDを持つエンティティに関連する子/関連エンドポイント。前に説明したのと同じパターンに従います。

1残念ながら、BREADはフリンジ用語のようです。CRUDウィキペディアの記事から：

CRUDのもう1つのバリエーションは、「参照、読み取り、編集、追加、削除」の頭字語であるBREADです。

私はそれがどのように聞こえるか、そしてそれが別個のブラウズアクションを持っていることを好みます。

于 2013-02-28T07:20:54.577 に答える
4

私は現在、リクエストが動詞で始まる3番目のオプションを使用しています。私の実装である理由は、典型的なRESTスタイルのURLに完全に基づいているわけではなく、c＃クライアントを広範囲に使用しています。このシナリオでは、動詞はサービスの目的を明確に識別するのに役立ちます。

私の特定のシナリオとは別に、私は

エンティティ：ムービーリクエスト：ムービーレスポンス：MovieResponse

于 2013-02-08T10:14:20.590 に答える