Html.RenderAction()을 사용하여 내보기를 렌더링하는 것이 적절할 때와 그렇지 않은 경우를 조금 알 수 있습니다. 나의 이해는 ASP.NET MVC의 '공식적인'구성 요소가 아니기 때문에 그것을 사용하는 것은 나쁜 습관이고 원래의 의도는 특정 컨트롤러 컨텍스트에 존재하지 않는 재사용 가능한 위젯에 대한 것이 었습니다.Html.RenderAction()을 사용하는 것이 적절한 경우?
RenderAction은 현재 뷰를 렌더링하고있는 컨트롤러가 아닌 다른 컨트롤러 아래에있는 구성 요소가 필요할 때 매우 유용합니다. 현재보기에서 데이터를 사용할 수없는 구성 요소를 렌더링하는 것은 매우 정돈 된 것 같습니다 (&). 내보기는 내가 사용하고있는 것처럼 모델을 제공 할 필요가 없습니다. RenderPartial()
이것은 나쁜 습관입니까? 더 좋은 방법이 있습니까?
문제가 해결되면 문제가되지 않습니다.
데이터에 의존하는 구성 요소를 현재보기에서 사용할 수 없도록 렌더링하는 것은 매우 정돈 된 것 같습니다 (&). RenderPartial()을 사용하는 경우와 같이 내보기에서 모델을 제공 할 필요가 없습니다.
실제로입니다. 예를 들어 위젯으로 사용할 소형 뷰를 만들어 필요할 때마다 삽입 할 수 있습니다. 그러나 위젯에서 사용자 입력을 처리하는 것은 복잡해 지지만 다른 문제입니다.
내가 생각할 수있는 또 하나의 합법적 인 시나리오는 HTML 이메일 템플릿을 사용하는 것입니다. 렌더링 된 결과를 브라우저에 직접 반환 할 필요는 없지만 전자 메일 본문에 삽입해야하는 경우가 있습니다.
당신이주는 이유 때문에 Html.RenderAction()을 사용하기 때문에 사용자 정보 (예 :)를 표시해야하는 모든 단일보기에 동일한 데이터를 반복해서 제공 할 필요가 없습니다. 뷰가 컨트롤러에 대해 알기 때문에 mvc 패턴을 위반한다고 주장 할 수 있습니다. 그러나이 시나리오의 장점이 그 이점보다 중요하며 귀하의 응용 프로그램이 더 DRY 될 것이라고 생각합니다.
많은 다른 장소 (예 : 마스터 페이지의 모든 페이지에 표시되는 사용자 데이터)에서 재사용해야하는 모든 항목에 간단히 사용하고 각 정보에 명시 적으로 정보를 보내지 않습니다. 내가 잘못 생각하지 않는다면 그들은 asp.net mvc 2에도 포함 시켰다고 생각합니다. 그래서 이제는 프레임 워크의 일부입니다.
상위 뷰의 모델 결과를 기반으로 시나리오에서 Html.RenderAction을 사용해야하는 큰 이유를 발견했습니다. 예를 들어 상위 뷰의 모델에는 테이블에 표시해야하는 List 속성이 있습니다. 그러나 부모보기에서 조건부 IF/ELSE를 방지하기 위해 Html.RenderAction()을 호출합니다. 액션은 목록을 받아 개수를 확인합니다. 카운트가 0이면 '결과 없음'보기를 반환합니다. 그렇지 않으면 List에있는 항목을 자체 모델 형식으로 처리하는보기를 반환합니다. 이것은 로직이 뷰에 삽입되는 것을 방지함으로써 더 깨끗합니다. 내 앱의 다른 영역에 대해서도 "결과 없음"뷰를 재사용 할 수 있습니다.