HTTPruntime 캐시와 HTTPContext 캐시의 차이점은 무엇입니까?

Question

나는 매우 비슷한 질문이 있다는 것을 알고 있습니다 여기 그러나 나는 더 나은 설명을 얻기를 바랐다. httpcontext가 실제로 httpruntime.cache를 사용하는 경우 httpruntime.cache 대신 httpcontext.cache를 사용해야하는 이유는 무엇입니까?

기사에서 ASP.NET을 사용하여 Windows 서비스를 시뮬레이션하여 예정된 작업을 실행합니다. Omar는 HTTPContext를 사용하여 캐시 항목을 저장하지만 Jeff Atwood가 구현했을 때 여기 그는 대신 httpruntime을 사용하기로 결정했습니다. 분명히이 특정 상황에서는 캐시 항목을 HTTPContext에 다시 추가하기 위해 웹 요청을 수행 할 필요가 없기 때문에 의미가 있습니다.

그러나 나는 하나와 다른 하나를 사용하는시기에 대한 좋은 포인터를 찾고 있습니다.

Answer 1

실제로는 마지막에 같은 캐시입니다. HttpContext.Current 때로는 무효 일 수 있습니다 (웹 컨텍스트가 아니거나 웹 컨텍스트에 있지 않지만 아직 구성되지는 않습니다). 항상 사용하는 것이 안전합니다 HttpRuntime.Cache.

Answer 2

일반 웹 페이지에있을 때 안전하게 사용할 수 있습니다. HttpContext.Cache 또는 그냥 Cache 페이지의 속성.

페이지에없는 일을하고 있다면 종종 사용해야합니다. HttpRuntime.Cache 안전하게 액세스하기 위해.

경우에 따라 HTTP 컨텍스트가 있는지 여부를 알 수 있습니다. 예를 들어 웹 페이지에서 별도의 스레드를 시작한 경우 해당 스레드에는 HTTP 컨텍스트가 없습니다. 다른 경우에는 때때로 HTTP 컨텍스트가있을 수 있습니다. Application_Start 방법 global.asax, 요청이 있기 때문에 응용 프로그램이 항상 시작되지 않을 수 있습니다.

Answer 3

우리 모두가 단지 돌아온다는 것을 알고 있지만 오해의 소지가 있습니다. HttpRuntime.Cache 내부적. 또한 httpruntime은 내가 추측하는 캐시를 노출시키기위한 나쁜 선택입니다.

모두가 어떻게 sais Session 세션 수준 캐시이고 우리가 말하는 캐시는 응용 프로그램 수준입니다. 나는 선호합니다 Application.Cache 오늘 우리가 사용하고 있습니다 HttpContext.Cache 알려진 것을 참조하기 위해 HttpContext.Items.

귀하의 질문에 답하기 위해, 우리는 모두 httpruntime.cache를 고수해야한다고 생각합니다. 그리고 진지하게 사용할 계획이라면 자신의 API를 감싸고 내부적으로 전화하는 것이 좋습니다. HttpRuntime's 또는 다른 캐시 구현 (Entlib, Velocity 등).