program tip

ASP.NET MVC-TempData-좋은 방법 또는 나쁜 방법

radiobox 2020. 8. 27. 07:40
반응형

ASP.NET MVC-TempData-좋은 방법 또는 나쁜 방법


AcceptVerbsASP.NET MVC에서 양식 항목을 처리하기 위해 Scott Gu의 Preview 5 블로그 게시물에 자세히 설명 된 방법을 사용하고 있습니다 .

  • 사용자는 GET을 통해 빈 양식을 얻습니다.
  • 사용자는 POST를 통해 채워진 양식을 동일한 작업에 게시합니다.
  • 작업은 데이터의 유효성을 검사하고 적절한 작업을 수행하며 새보기로 리디렉션합니다.

그래서 나는 사용할 필요가 없습니다 TempData. 즉, 이제이 프로세스에 '확인'단계를 추가해야하며 TempData.

어떤 이유로, 나는 TempData그것을 사용하는 것을 싫어합니다 .

이것이 타당한 우려입니까, 아니면 제가 구성하고 있습니까?


저는 임시 데이터를 사용자에게 알리기위한 화재 및 잊어 버리기 메커니즘이라고 생각합니다. 최근에 한 일을 상기시켜주는 것이 좋지만 일부 사용자 프로세스에서 필수 단계로 만드는 것도 주저합니다. 그 이유는 그들이 페이지를 새로 고치면 사라질 것이라고 믿습니다. 글쎄, 나는 그것이 얼마나 신뢰할 수 있는지 잘 정의되지 않았기 때문에 그것을 사용하는 것을 주저한다고 생각합니다.

확인 단계 전에 작업이 다른 페이지로 리디렉션되는 것이 문제인지 궁금합니다. 대신 그들이 처음 제출 한 후에 확인 대화 상자를 생성하고 확인 질문이있는 원본 페이지를 반환 할 수있을만큼 충분한 처리를 수행 할 수 있는지 궁금합니다. 유효성 검사 규칙이 확인 단계가 수행되었는지 여부를 확인한다는 점을 제외하면 유효성 검사 방법과 유사합니다 (다른 유효성 검사가 통과 할 때까지 확인 UI가 숨겨 짐).


TempData에 대한 혐오감을 가질 필요는 없습니다.하지만 올바르게 사용하지 않으면 디자인이 잘못되었음을 나타낼 수 있습니다. RESTful URL을 사용하는 경우 TempData는 POST 작업에서 GET 작업으로 메시지를 전송하는 모범 사례입니다. 이걸 고려하세요:

URL Products / New에 양식이 있습니다. 양식의 유효성을 검사하고 제품을 만드는 Posts to Products / Create 양식은 성공시 컨트롤러가 URL Products / 1로 리디렉션하고 오류시 제품 / 신규로 다시 리디렉션되어 오류 메시지를 표시합니다.

Products / 1은 제품에 대한 표준 GET 작업이지만 삽입이 성공했음을 나타내는 메시지를 표시하려고합니다. TempData는 이것에 완벽합니다. Post Controller의 TempData에 메시지를 추가하고 if 로직을 뷰에 넣고 완료하십시오.

실패하면 formCollection에 입력 된 값과 Post Action의 TempData에 오류 메시지 모음을 추가하고 초기 Action Prodcuts / New로 리디렉션했습니다. 오류 메시지와 함께 이전에 입력 한 값으로 양식 입력을 채우는 논리를보기에 추가했습니다. 나에게 멋지고 깨끗한 것 같습니다!


TempData를 사용하기 전에 주저하는 것이 좋습니다. TempData는 세션에 저장되며 다음과 같은 경우 영향을 미칠 수 있습니다.

  1. 현재 사이트에서 세션을 사용하지 않습니다.
  2. 높은 처리량으로 확장해야하는 시스템이 있습니다. 즉, 세션 상태를 완전히 피하는 것이 좋습니다.
  3. 쿠키를 사용하고 싶지 않습니다 (현재 MVC가 쿠키없는 세션을 얼마나 잘 지원하는지 모르겠습니다)

사이트에 고 가용성이 필요한 경우 세션 상태 적용에 대한 추가 고려 사항이 있지만 모두 해결할 수있는 문제입니다.


먼저 TempData [ "model"]를 확인하고 반환하는 GetModel 메서드가 있습니다. 그렇지 않으면 GetModel은 데이터베이스에서 적절한 데이터를로드합니다.

동일한 모델 데이터가 필요한 다른 뷰를 반환해야하는 작업이있을 때 데이터베이스에서 추가로드를 절약합니다.


MVC3 에서 세션 없는 컨트롤러확인하십시오 . 세션을 사용하면 단일 사용자 요청의 병렬 실행이 방지되어 성능이 저하되는 것으로 나타났습니다.

tempdata는 기본적으로 세션을 사용하므로이 기능을 사용할 수 없습니다. 임시 데이터에 쿠키를 사용하도록 전환 할 수 있지만 약간 어색합니다 (적어도 저에게는). 그래도 viewstate보다 깨끗하기 때문에 그렇게 큰 문제가 아닐 수도 있습니다.


왜 그런 혐오감을 가지고 있습니까? 이것은 단순히 일을하고 잘 만드는 것입니다 :)

강력하지 않은 유형으로 인해 마음에 들지 않으면 항상 강력한 유형의 인터페이스를 제공하는 래퍼를 만들 수 있습니다.


ViewData를 사용하는 것과 같으므로 보안 위험이 아닐 수 있습니다. 하지만 TempData보다 ViewData를 사용하고 싶습니다. 비교는 여기에서 확인하십시오 : http://www.squaredroot.com/2007/12/20/mvc-viewdata-vs-tempdata/

디자인에 따라 항상 사용자 / 바구니 또는 데이터베이스의 임시 데이터에 필요한 모든 것을 저장할 수 있으며 완료 여부를 나타내는 "IsReady"필드 만 있으면 나중에 사용할 수 있도록 확장 할 수 있습니다. 사람들은 브라우저를 닫을 수 있습니다.


모든 좋은 대답, 메시지 전달을 위해 이것을 보셨습니까?

TempData 및 Session은 대부분의 세션이 메모리에 저장되므로 RESTful 아키텍처에 가장 적합한 아이디어가 아닙니다. 따라서 서버 팜을 사용하려는 경우 사용자 세션은 한 서버에 존재하고 다음 요청은 다른 서버로 전송 될 수 있습니다.

여기서 메시지를 전달하기 위해 TempData를 사용하는 방법을 살펴보십시오.

http://jameschambers.com/2014/06/day-14-bootstrap-alerts-and-mvc-framework-tempdata/

Mabye 이것은 다른 페이지 경고로의 리디렉션에만 사용되는 경우 쿼리 문자열 접근 방식을 사용하도록 조정할 수 있습니다.

참고 URL : https://stackoverflow.com/questions/386681/asp-net-mvc-tempdata-good-or-bad-practice

반응형