0

そのため、クライアントがサーバーに値を渡す方法は複数あります。リクエストの本文、ヘッダー、および/または Cookie。

サーバー側では、これらの値は、ModelBinders、ValueProviders、MediaFormatters、FromBody、FromUri、Dependency によって取得できます。現在の http コンテキストから読み取るコンポーネントを挿入するか、現在の HTTP コンテキストから直接読み取る (これは単体テストにとって最悪のものであることはわかっています。 、絶対にしないでください）。

問題は、どちらを何に使用するかをどのように決定するかです。

私が思うに、すべてのユーザー入力は ModelBinder を使用します。それ以外の場合は、ヘッダーの認証トークンなど、モデル バインダーを使用せずに認証属性を使用します。ヘッダーまたは Cookie から読み取ります。

cartId のようなものがあり、カート内のアイテム、配送先住所、支払い先住所などを更新している場合はどうでしょうか。ここで、DDD カートを使用すると、ルート オブジェクトである必要があり、アイテム、配送先住所、および支払いが子である必要があります。リクエストは、カートと依存オブジェクトを受け取る必要があります。しかし、それは非常に大きな負荷になります。では、cartId だけを渡さない理由と、その cartId を Cookie に保存しない理由と、それを行う場合。CartId の値をどのように読み取るか、ModelBinder を使用するか、現在の HTTP コンテキストからそれを読み取るコンポーネントを依存関係に挿入するか、現在の HTTP コンテキストから直接読み取る必要があります (単体テストではこれが最悪であることはわかっています。したがって、決して実行しないでください)。

したがって、認証トークンまたはセッション トークンではなく、アクション メソッドで必要な ID です。ただし、リクエスト本文またはクエリ文字列の入力として渡されていません。そのようなパラメータを読み取るための最良の方法は何ですか

4

1 に答える 1

1

cartId のようなものがあり、カート内のアイテム、配送先住所、支払い先住所などを更新している場合はどうでしょうか。ここで、DDD カートを使用すると、ルート オブジェクトである必要があり、アイテム、配送先住所、および支払いが子である必要があります。リクエストは、カートと依存オブジェクトを受け取る必要があります。

DDD と HTTP/REST を混同しないでください。DDD はドメイン用です。HTTP/REST は Web リソース用です。

なぜこのようなものではないのですか？

add product to the cart
POST /my/carts/1/products { body/model: productId=6&quantity=2 }

update quantity
PUT /my/carts/1/products/6 {body/model: quantity=4 }

...そして、私はあなたの DDD 設計について議論しなければなりません。配送先住所と請求先住所は、カートの集計ではなく、実際には注文の集計の一部です。しかし、私は脱線します...

HTTP リソースを編成して DDD 集計を模倣する場合、各リクエストでカート全体を渡す必要はありません。さまざまなユーザー アクションで、さまざまなリソース/メソッドの組み合わせを呼び出して、集計を操作することができます。リクエストの本文と一緒に cartId を送信する必要さえありません。これはすでに URL に含まれているためです。

[POST("my/carts/{cartId:int}/products")]
public HttpResponseMessage PostProduct(int cartId, CartProductPostModel model)
{
    // ensure user owns the cart (based on cookie or authentication info)
    // get the cart aggregate based on the cartId,
    // add the product to the cart
    // tell the client you succeeded by passing back an appropriate response
    // 201 Created
    // Location: http://www.site.com/my/carts/1/products/6
    // note the response does not send back the whole cart, it only tells you
    // the new resource was created and where you can access it
}

HTTP リソース URL を RESTful に設計する場合、ヘッダー、Cookie、セッションなどで ID を渡す必要はありません。これは、必要なすべての情報が既に要求に含まれているためです (URL 自体またはいずれか)。リクエスト本文で。

アップデート

したがって、この場合、cartId は整数ではなく、実際には "/" を含む文字列です (IIS/ASP.net MVC は失敗します)。私は奇妙だと知っていますが、それはそれであり、私はそれを変更することはできません. したがって、URL の一部として存在することはできません。クエリ文字列の一部である可能性があります。ただし、他のクライアントと相互運用するには。私たちはそれをクッキーに入れることを余儀なくされています。

はい、URLに入れることができます。最初にエンコードするだけです。したがって、次のようなカート IDcart/with/slashesは、URL で次のようになります。

add product to the cart
POST /my/carts/cart%2fwith%2fslashes/products

update quantity
PUT /my/carts/cart%2fwith%2fslashes/products/6

これは、MVC ルーティングでも WebAPI ルーティングでも問題なく機能します。

[POST("my/carts/{cartId}/products")]
public HttpResponseMessage PostProduct(string cartId, CartProductPostModel model)
{
    // cartId will be "cart/with/slashes", decoded
}
于 2013-08-09T18:00:01.090 に答える