세션 변수 대 로컬 변수는

Question

, 나는이 같은 수행하여 세션에 액세스해야하는 횟수를 최소화하는 습관을 포착 한 :

private List<SearchResult> searchResults; 

private List<JobSearchResult> SearchResults 
    { 
     get 
     { 
      return searchResults ?? (searchResults = Session["SearchResults"] as List<SearchResult>); 
     } 

     set 
     { 
      searchResults = value; 
      Session["SearchResults"] = value; 
     } 
    } 

내 객체가 포스트 백을 통해 여러 번 사용된다면 객체는 세션에서 덜 자주 검색되어야한다고 추론합니다. 그러나 이것이 실제로 성능 측면에서 실제로 도움이되는지, 아니면 실제로 시간 낭비인지 또는 나쁜 생각인지는 전혀 알 수 없습니다. 누구든지 세션에서 객체를 끌어내는 것이 계산 상 비싸다는 것을 알고 있다면 위의 접근법과 비교할 수 있을까요? 아니면 이것을 둘러싼 모범 사례가 있습니까?

Answer 1

사용중인 세션 저장 장치 유형에 따라 다릅니다 (자세한 내용은 here 참조).

InProc 저장소를 사용하는 경우 개체에 매우 자주 액세스하지 않는 한 성능 차이가 거의 없을 수 있습니다. 그러나 로컬 복사본은 실제로 어느 쪽이든 아프지 않습니다.

Answer 2

저장되는 데이터의 크기, 대역폭 (인터넷 또는 LAN), 응용 프로그램의 규모에 따라 다릅니다. 데이터 크기가 작고 대역폭이 충분하면 (LAN), 규모가 전 세계적으로 (예 : Whitehouse.gov) 클라이언트 측에 양식 숨겨진 매개 변수로 저장해야합니다. 다른 상황에서는 (데이터 크기가 매우 크고 대역폭이 매우 낮고 규모가 작습니다 (3 ~ 4 명만이 애플리케이션을 사용합니다), 서버 측 (세션)에 저장할 수 있습니다. 이 결정을 고려하여 고려해야 할 요소 또한 세션 객체에서 하나의 필드 만 사용하는 것은 권장하지 않습니다. 사전 (Java의 HashMap)을 세션에서 만들고 저장소로 사용하고 사용자가 다음 키를 전달해야합니다. 이 사전은이 데이터를 얻을 수 여러 탭에서 웹 사이트를 열 수있는 사용자 기능을 제공하기 위해 필요한 URL의

예, 필요한 검색 접근 :..

http://www.mysite.com/SearchResult.aspx?search_result=d38e8df908097d46d287f64e67ea6e1a 

Answer 3

은 확실히 당신의 S에 따라 달라집니다 torage Unit하지만 스토리지가 InProc이 아닌 경우 DeSerialization을 방지하기 때문에 어느 경우에도 좋은 접근 방법입니다. InProc의 경우에도 Boxing \ UnBoxing을 방지합니다 ... 내 투표가 귀하의 접근 방식을 선호합니다.

Answer 4

나는 당신의 접근 방식에 아무런 문제가 없음을 본다. 유일한 단점은 비공개 필드가 초기화 된 후에 다른 일부 코드 (또는 다른 사람의 코드)가 세션 값을 변경하면 래퍼 속성은 여전히 ​​이전 값을 반환한다는 것입니다. 즉, 귀하의 부동산이 첫 번째 시간을 제외하고 실제로 세션 값을 반환한다는 보장은 없습니다.

성능면에서 InProc의 경우 거의 이득이 없다고 생각합니다. 다른 사전과 변수 저장과 비슷합니다. 그러나 다른 세션 저장 모드를 사용할 때 차이가 발생할 수 있습니다. 그리고 앱을 프로파일 링하고 알아낼 수 있다는 것을 정말로 알고 싶다면;) 2 개의 트레이스 쓰기와 루프 된 세션 읽기/쓰기와 같은 간단한 것을 시도해 볼 수도 있습니다. http://www.codeproject.com/KB/session/ASPNETSessionInternals.aspx