1

これは、以前のスタックオーバーフローの質問（リンクテキスト）の続きです。

{id}で終わるデフォルトのルーティング定義を使用する場合、ターゲットがActionLinkが存在するページを生成したのと同じメソッドであるActionLinkがある場合、フレームワークは自動的にコールバックURLにidを含めます。それを要求しませんでした。

たとえば、次のURLのページを表示している場合：

http://www.somedomain.com/AController/SameMethod/456

また、ページcshtmlファイルには次のようなActionLinkがあります。

@Html.ActionLink("some text", "SameMethod", ARouteValueDictionary, SomeHtmlAttributes)

次に、ARouteValueDictionaryに「id」が含まれているかどうかに関係なく、生成されたURLに表示されます。

これは、最初にページを生成したのと同じメソッドにコールバックした場合にのみ発生します。同じコントローラー上の別のメソッドにコールバックした場合、{id}フィールドは生成されたURLに挿入されません。

私は必ずしもこれに問題があるわけではありません。しかし、なぜデザイナーがこのアプローチを採用したのか興味があります。

参考までに、私は自分のWebサイトのデザインで誤ってこの機能に依存していたため、この機能を発見しました。IDフィールドを他の多くの情報とともにサーバーに返す必要があります...RouteValueDictionaryにID情報を明示的に追加したことはありません。しかし、私のコールバックのほとんどは、最初にページを生成したのと同じアクションメソッドに対するものだったので、とにかく情報を含めていました。

新しいコンポーネント（すでに機能していたものと「本質的に同一」であると確信していた）が失敗したときの私の驚きを想像することができます。しかし、新しいコンポーネントのターゲットアクション方法が異なるため、魔法はなくなりました。

編集：

生成されたURLに{id}フィールドを含めることは、最初にページを生成したのと同じメソッドを呼び出すことを条件とすることを明確にするために、説明を変更しました。

4

1 に答える 1

0

...フレームワークは、リクエストしていなくても、コールバック URL に ID を自動的に含めます。

私は「自動的に」よりも「環境的に」という用語を好みます。既に URL に含まれているルート トークンは、HtmlHelper および UrlHelpers に対して "アンビエント" と考えることができます。

しかし、デザイナーがこのアプローチを採用した理由については興味があります。

たとえば、5 つのアクションをグループ化するコントローラーを考えてみましょう。これらの 5 つは相互にリンクしている可能性がありますが、グループ外のリンクは多くありません。Html.Action の最も単純なオーバーロードは、レンダリングするテキストとアクション名の 2 つの引数のみを取ります。

これは、これらのビュー内のアクションからアクションへのリンクの省略形になります。それらはすべて同じコントローラー上にあり、そのコントローラーは既に現在のアクションのパスにあるため、ヘルパー メソッドでコントローラー名を指定しない場合、MVC はこの値を再利用します。同じ動作が {id} または定義したその他のルート トークンにも適用されます。

于 2012-07-14T07:10:37.033 に答える