MVC : ActionLink는 ID 필드를 기억합니까?

Question

이것은 이전 stackoverflow 질문 (link text)의 후속 조치입니다.

{id}로 끝나는 기본 라우팅 정의를 사용하는 경우 ActionLink가있는 페이지와 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에 삽입되지 않습니다.

필자는 이것에 반드시 문제가있는 것은 아닙니다. 그러나 나는 에 대해 궁금해합니다. 왜 디자이너가이 방법을 택했는지.

나는이 기능을 실수로 내 웹 사이트 디자인에 의존했기 때문에이 기능을 발견했습니다. ID 필드를 다른 정보와 함께 서버에 다시 전달해야합니다 ... ID 정보를 RouteValueDictionary에 명시 적으로 추가하지 않았을뿐입니다. 그러나 대부분의 콜백은 처음부터 페이지를 생성 한 것과 동일한 액션 메소드에 있었기 때문에 어쨌든 정보를 포함하고있었습니다.

새로운 구성 요소가 이미 작동하고 있던 것과 "본질적으로 동일"하다고 확신 했는데도 놀랍습니다. 그러나 새로운 구성 요소가 다른 목표 행동 방법을 가지고 있었기 때문에 마술은 사라졌습니다.

편집 :

생성 된 URL에 처음에 페이지를 생성과 같은 방법을 호출에 달려있는 {ID} 필드를 포함 것을 명확하게 설명을 수정.

Answer 1

... 프레임 워크는 자동으로 요청하지 않은 경우에도 콜백 URL에 의 ID를 포함합니다.

나는 "자동적으로"라는 용어를 "ambiently"라고합니다. 이미 URL에있는 경로 토큰을 HtmlHelper 및 UrlHelpers에 "주변"이라고 생각할 수 있습니다.

그러나 디자이너가이 접근법을 사용하는 이유에 대해 궁금합니다.

5 개의 동작을 함께 그룹화하는 컨트롤러를 생각해보십시오. 이들 5 명은 서로 링크되어있을 수 있지만 그룹 외부의 링크는 많지 않습니다. 가장 간단한 Html.Action 오버로드는 렌더링 할 텍스트와 액션 이름의 두 가지 인수 만 사용합니다.

이렇게하면 이러한보기 내에서 동작에서 동작으로 연결되는 약식이 만들어집니다.모든 컨트롤러가 동일한 컨트롤러에 있고 해당 컨트롤러가 이미 현재 작업의 경로에 있으므로 MVC는 도우미 메서드에서 컨트롤러 이름을 지정하지 않으면이 값을 다시 사용합니다. 동일한 동작이 {id} 또는 사용자가 정의한 다른 경로 토큰으로 확장됩니다.