PHP : $ _SESSION 안에 '객체'저장하기

PHP : $ _SESSION 안에 '객체'저장하기

나는 실제로 $ _SESSION에 객체를 저장할 수 있다는 것을 알았고 다른 페이지로 건너 뛸 때 여전히 객체를 가지고 있기 때문에 아주 멋지다. 이제는이 접근법을 사용하기 전에 정말 좋은 아이디어인지 또는 잠재적 함정이 관련되어 있는지 알아보고자합니다.

나는 내가 입장의 단일 지점을 가졌다면 그렇게 할 필요는 없지만 나는 아직 거기 있지 않기 때문에 나는 입장의 단일 지점을 가지고 있지 않으며 나는 나의 목표를 지키고 싶다. 그런 식으로 내 상태를 잃어 버리지 마라. (이제는 stateless 사이트를 프로그래밍해야한다는 것을 알았지 만 아직 그 개념을 이해하지 못했습니다.)

그래서 간단히 말해서, 세션에 객체를 저장하는 것이 괜찮습니까? 거기에 문제가 있습니까?

편집하다:

임시 요약 : 지금까지 데이터베이스를 다시 쿼리하는 경우에도 개체를 다시 만드는 것이 더 좋습니다.

추가 답변은 아마도 그 측면에 대해 더 자세히 설명 할 수 있습니다!

해결법

1. ==============================

   1.나는이 화제가 오래되었다는 것을 알고있다, 그러나이 문제점은 오르고 유지하고 나의 만족으로 제시되지 않았다 :

   나는이 화제가 오래되었다는 것을 알고있다, 그러나이 문제점은 오르고 유지하고 나의 만족으로 제시되지 않았다 :

   숨겨진 양식 필드에 숨겨진 데이터를 기반으로 $ _SESSION에 객체를 저장하거나 전체 옷감을 재구성하거나 매번 DB에서 다시 쿼리하는지 여부에 관계없이 상태를 사용하고 있습니다. HTTP는 상태 비 저장 (다소 차이가 있지만 GET과 PUT 참조)하지만 웹 애플리케이션으로 할 수있는 거의 모든 것이 상태가 유지되어야합니다. 국가를 구석 구석으로 밀어 넣는 것이 이론적 인 승리의 일부가되는 것처럼 행동하는 것은 잘못된 것입니다. 상태는 상태입니다. 상태를 사용하면 무국적으로 얻는 다양한 기술적 이점을 잃게됩니다. 이것은 당신이 그 위에 잠을 자고 있어야한다는 것을 미리 안다면, 잠을 자지 못하는 것이 아닙니다.

   저는 특히 행크 게이가 제기 한 "이중 whammy"논쟁에 의해받은 축복에 난처합니다. OP 빌딩은 분산되고 부하가 분산 된 전자 상거래 시스템입니까? 내 추측은 '아니오'입니다. 그리고 나는 $ User 클래스를 직렬화하는 것이 무엇이든, 수리를 넘어 서버를 손상시키지 않을 것이라고 가정 할 것이다. 내 충고 : 응용 프로그램에 합리적인 기술을 사용하십시오. $ _SESSION의 객체는 상식적인주의 사항에 따라 문제가 없습니다. 앱이 갑자기 트래픽이 발생한 Amazon과 경쟁하게되면 재 적응해야합니다. 인생이 다 그렇지.

2. ==============================

   2.session_start () 호출이있을 때까지 이미 PHP가 클래스 선언 / 정의를 찾았거나 이미 설치된 오토로더에서 찾을 수있는 한 괜찮습니다. 그렇지 않으면 세션 저장소에서 개체를 deserialize 할 수 없습니다.

   session_start () 호출이있을 때까지 이미 PHP가 클래스 선언 / 정의를 찾았거나 이미 설치된 오토로더에서 찾을 수있는 한 괜찮습니다. 그렇지 않으면 세션 저장소에서 개체를 deserialize 할 수 없습니다.

3. ==============================

   3.HTTP는 이유가없는 상태없는 프로토콜입니다. 세션이 HTTP에 상태를 용접합니다. 일반적으로 세션 상태는 사용하지 마십시오.

   HTTP는 이유가없는 상태없는 프로토콜입니다. 세션이 HTTP에 상태를 용접합니다. 일반적으로 세션 상태는 사용하지 마십시오.

   최신 정보: HTTP 레벨에는 세션에 대한 개념이 없습니다. 서버는 클라이언트에게 고유 한 ID를 제공하고 모든 요청에 ​​대해 클라이언트에 다시 제출하도록 지시함으로써이를 제공합니다. 그런 다음 서버는 해당 ID를 세션 객체의 큰 해시 테이블에 대한 키로 사용합니다. 서버는 요청을받을 때마다 클라이언트가 요청과 함께 제출 한 ID를 기반으로 세션 객체의 해시 테이블에서 세션 정보를 찾습니다. 이 모든 추가 작업은 확장성에 두 배의 타격을줍니다 (HTTP가 무국적 인 이유가 큰 이유).

   이 모든 것을 감안할 때 세션에 추가하는 정보가 많을수록 성능에 미치는 영향이 커집니다 (Vinko가 지적했듯이). Vinko가 지적했듯이 객체가 직렬화 가능하지 않으면 세션이 잘못 될 것입니다. 따라서 엄지 손가락으로는 절대적으로 필요한 것 이상을 세션에 두지 마십시오.

   @Vinko 추적하는 데이터를 사용자가 보낸 응답에 포함시키고 클라이언트가 다시 제출하도록 (예 : 숨겨진 입력으로 데이터 보내기) 서버 저장소 상태를 유지할 수 있습니다. 서버 측에서 상태를 추적해야하는 경우 백업 데이터 저장소에 있어야합니다.

   Vinko는 PHP가 세션 정보를 저장하기 위해 데이터베이스를 사용할 수 있고, 클라이언트가 잠재적 인 확장 성 문제를 해결할 때마다 데이터를 다시 제출하게하면서 클라이언트가 모든 것을 제어 할 수있게되었습니다. 당신의 상태)

4. ==============================

   4.그 외에는 아무 문제도 보지 못했습니다.

   그 외에는 아무 문제도 보지 못했습니다.

5. ==============================

   5.내 경험상, 일반적으로 몇 가지 속성을 가진 StdClass보다 더 복잡한 것은 그다지 가치가 없습니다. 비 직렬화의 비용은 세션 저장 식별자가 주어지면 항상 데이터베이스에서 재 작성하는 것 이상의 의미가 있습니다. 멋지지만 (항상 그렇듯이) 프로파일 링이 핵심입니다.

   내 경험상, 일반적으로 몇 가지 속성을 가진 StdClass보다 더 복잡한 것은 그다지 가치가 없습니다. 비 직렬화의 비용은 세션 저장 식별자가 주어지면 항상 데이터베이스에서 재 작성하는 것 이상의 의미가 있습니다. 멋지지만 (항상 그렇듯이) 프로파일 링이 핵심입니다.

6. ==============================

   6.당신이 절실히 필요로하지 않는 한 나는 국가를 사용하지 말 것을 제안합니다. 세션을 사용하지 않고 객체를 재 구축 할 수 있다면 수행하십시오. 웹 응용 프로그램에 상태가 있으면 응용 프로그램을 더 복잡하게 만들어 모든 요청에 ​​대해 사용자가 어떤 상태인지 파악해야합니다. 세션을 사용하는 것을 피할 수없는 경우가 있습니다 (예 : 사용자가 자신의 세션 중에 로그인 상태를 유지해야 함). 웹 응용 프로그램). 마지막으로 세션 객체를 가능한 작게 유지하는 것이 성능에 영향을 미치기 때문에 큰 객체를 직렬화 및 직렬화 해제하는 것이 좋습니다.

   당신이 절실히 필요로하지 않는 한 나는 국가를 사용하지 말 것을 제안합니다. 세션을 사용하지 않고 객체를 재 구축 할 수 있다면 수행하십시오. 웹 응용 프로그램에 상태가 있으면 응용 프로그램을 더 복잡하게 만들어 모든 요청에 ​​대해 사용자가 어떤 상태인지 파악해야합니다. 세션을 사용하는 것을 피할 수없는 경우가 있습니다 (예 : 사용자가 자신의 세션 중에 로그인 상태를 유지해야 함). 웹 응용 프로그램). 마지막으로 세션 객체를 가능한 작게 유지하는 것이 성능에 영향을 미치기 때문에 큰 객체를 직렬화 및 직렬화 해제하는 것이 좋습니다.

7. ==============================

   7.페이지로드 사이에는 리소스 유형 (예 : db 연결 또는 파일 포인터)이 유지되지 않는다는 점을 기억해야하며,이를 눈에 보이지 않게 다시 작성해야합니다.

   페이지로드 사이에는 리소스 유형 (예 : db 연결 또는 파일 포인터)이 유지되지 않는다는 점을 기억해야하며,이를 눈에 보이지 않게 다시 작성해야합니다.

   또한 저장 방법, 크기 제한 또는 대기 시간 문제에 따라 세션의 크기를 고려하십시오.

8. ==============================

   8.또한 소프트웨어 라이브러리를 업그레이드 할 때 - 우리는 소프트웨어를 업그레이드했고 이전 버전에는 V1 소프트웨어의 클래스 이름과 세션에있는 객체가 있었지만 새 소프트웨어는 세션에 있던 객체를 만들려고 할 때 충돌했습니다. - V2 소프트웨어는 더 이상 같은 클래스를 사용하지 않았으므로 찾을 수 없습니다. 우리는 세션 객체를 감지하기 위해 수정 코드를 입력하고, 발견 된 경우 세션을 삭제하고, 페이지를 다시로드해야했습니다. 가장 큰 고통은 처음에 당신이이 버그를 처음으로보고했을 때 마음에 들었던 것이 었습니다. (너무 익숙한, "글쎄요, 저에게는 효과가 있습니다":) 이것은 오래된 시스템과 새로운 시스템이 최근 어디서 왔는지 사람들에게만 영향을주었습니다. 우리는 모든 사용자가 자신의 세션에서 이전 세션 변수를 가지고 있었고 잠재적으로 모두에게 추락했을 것입니다. 끔찍한 발사 였을 것입니다.

   또한 소프트웨어 라이브러리를 업그레이드 할 때 - 우리는 소프트웨어를 업그레이드했고 이전 버전에는 V1 소프트웨어의 클래스 이름과 세션에있는 객체가 있었지만 새 소프트웨어는 세션에 있던 객체를 만들려고 할 때 충돌했습니다. - V2 소프트웨어는 더 이상 같은 클래스를 사용하지 않았으므로 찾을 수 없습니다. 우리는 세션 객체를 감지하기 위해 수정 코드를 입력하고, 발견 된 경우 세션을 삭제하고, 페이지를 다시로드해야했습니다. 가장 큰 고통은 처음에 당신이이 버그를 처음으로보고했을 때 마음에 들었던 것이 었습니다. (너무 익숙한, "글쎄요, 저에게는 효과가 있습니다":) 이것은 오래된 시스템과 새로운 시스템이 최근 어디서 왔는지 사람들에게만 영향을주었습니다. 우리는 모든 사용자가 자신의 세션에서 이전 세션 변수를 가지고 있었고 잠재적으로 모두에게 추락했을 것입니다. 끔찍한 발사 였을 것입니다.

   어쨌든, 당신이 수정안에서 제안한 것처럼, 나는 또한 객체를 다시 만드는 것이 낫다고 생각합니다. 그래서 id를 저장 한 다음 데이터베이스에서 객체를 가져 오는 요청이있을 때마다 더 좋고 / 더 안전합니다.

from https://stackoverflow.com/questions/132194/php-storing-objects-inside-the-session by cc-by-sa and MIT license