これは別の場所で回答されていると確信していますが、決定的な投稿がどこにも見つからないようです。
階層ルーティングに関する投稿のほとんどは、Url に無制限の数のトークンが必要な場合について語っています。私の質問は、特定のエンティティが別のエンティティのコンテキストに関連付けられずに存在することが意味をなさない場合について詳しく説明します。
たとえば、Contract エンティティと予想される Contract コントローラーがあります。インデックス、編集、作成などの標準アクションがあります。私のURLは次のようになります
/Contracts/ ' list all contracts
/Contracts/Create/ ' display form to create new contract
/Contracts/Edit/87Y5r3/ ' display form to edit contract 87Y5r3
ここで、特定の契約に関連付ける必要がある I Order エンティティを想像してください。（ほぼ）デフォルトのルーティングを使用すると、次のURLが得られます
/Orders/ ' display all orders across all contracts
/Orders/Index/87Y5r3 ' display all orders for contract 87Y5r3
/Orders/Create/87Y5r3 ' display form to create new order for contract 87Y5r3
/Orders/Edit/87Y5r3/45 ' display form to edit order 45 under contract 87Y5r3
もちろん、ほぼデフォルトのルーティングのままにして、契約番号や注文番号などの追加パラメーターをサポートするように微調整することもできます。
または、ルーティングを変更して、注文が階層内の契約の下にあることを示すことができます。私が見ているように、私には追求すべきいくつかの道があります。
1) コントラクトとオーダーの両方を処理する単一のコントローラーと、アクションをメソッドにマッピングするための多数のカスタム ルートを用意します。これにより、次のようなURLが得られます
/Contracts/ ' maps to Index action in the Contract controller
/Contracts/Create/ ' maps to Create action in the Contract controller
/Contracts/Orders/ ' maps to IndexOrders action in the Contract controller
/Contracts/Orders/Index/87Y5r3 ' maps to IndexOrders action in the Contract controller
/Contracts/Orders/Edit/87Y5r3/45 ' maps to EditOrders action in the Contract controller
コントローラーを 1 つだけ持つことについての適切な議論は想像できませんが、これは適切なルートを持つ Contracts コントローラーと Orders コントローラーに分割することもできると推測しています。
考慮すべき主なポイントは、契約番号が URL の末尾に向かってくるということです。
2) 別のオプションは別のコントローラーですが、次の URL があります。これは私にはもう少し自然（論理的）に思えます。
/Contracts/ ' maps to Index action in the Contract controller
/Contracts/Create/ ' maps to Create action in the Contract controller
/Contracts/?????/87Y5r3/Orders/Index/ ' maps to Index action in the Order controller
/Contracts/?????/87Y5r3/Orders/Edit/45 ' maps to Edit action in the Order controller
/Contracts/?????/All/Orders/ ' maps to Index action in the Order controller
この場合、コントラクト番号は Url のコントラクト トークンの後にあり、注文番号は最後に来ます。いくつかの問題/懸念事項を特定しました
すべての契約にまたがる注文データの処理方法。ご覧のとおり、特別な「すべて」トークンで処理されています。
URL の契約部分に使用するアクションは何ですか。デフォルトでは、Mvc のルーティングは /{controller}/{action}/{id} です。
3)私が投稿した 3 番目のオプション (ただし、長所と短所を評価するには十分に理解していません) は、RESTful API を使用することです。これにより、注文を処理するときに契約に使用するアクションについての私の 2 番目の懸念が解決されると思います (??)。基本的な考え方は、アクションを DELETE や PUT などの HTTP 動詞に置き換えて、Url の末尾にあるエンティティにのみ適用する必要があるというものです。
この場合、私は次のようなものになります
GET /Contracts/ ' コントラクト コントローラーの Index アクションにマップ POST /Contracts/Create/ ' コントラクト コントローラーの Create アクションにマップ GET /Contracts/87Y5r3/Orders/ ' オーダー コントローラーの Index アクションにマップ PUT /Contracts/87Y5r3 /Orders/45 ' 注文コントローラーの Edit アクションにマップします GET /Contracts/All/Orders/ ' 注文コントローラーの Index アクションにマップします
RESTful が進むべき道かもしれませんが、私はそれについて十分に知りません。私の最初の反応は、複雑さと制限 (動詞がいくつあるか???) が追加され、その有用性が制限される可能性があるということです。
私の簡単な読書に基づいて、RESTful アプローチ (以下の @Robotsushi によって提案された ASP.NET Web API を含む) を使用しても、実際には私の質問には答えません。ページが AJAX と JSON 経由でデータを要求している場合、RESTful を検討する必要があるようです。その意味で (データのみを要求する)、Url へのアプローチを提供します。ただし、私の質問は、アクションがモデルをビューに渡す標準の MVC モデルに重点を置いています。結局のところ、ユーザーに Web ページを提示する必要があります...
私はこれを明確に要約しましたか？私が見逃している他の戦略はありますか？これはかなり一般的なシナリオでなければならないので、大量の記事が見つからないことに驚いています。
例を少し単純化しましたが、私の場合、実際にはこれを 3 番目のレベル (契約 / 注文 / プロジェクト) に引き上げる必要があります。
ありがとう