방금 $ _SESSION에 객체를 저장할 수 있다는 것을 알았 습니다. 다른 페이지로 이동할 때 여전히 객체가 있기 때문에 꽤 멋집니다. 이제이 방법을 사용하기 전에 이것이 실제로 좋은 아이디어인지 또는 잠재적 인 함정 이 있는지 확인하고 싶습니다 .
단일 진입 점을 가지고 있다면 그렇게 할 필요는 없지만 아직 거기에 없기 때문에 단일 진입 점이 없으며 실제로 물건을 보관하고 싶습니다. 내 상태를 잃어 버리지 (이제 상태 비 저장 사이트를 프로그래밍해야하지만 해당 개념을 아직 이해하지 못한다는 내용도 읽었습니다.)
그래서 짧은 :이 세션에서 저장 개체에 대한 확인인가, 그것으로 어떤 문제가 있습니까?
편집하다:
임시 요약 : 이제는 데이터베이스를 다시 쿼리해야하더라도 개체 를 다시 만드는 것이 좋습니다 .
추가 답변은 해당 측면 에서 좀 더 정교 해질 수 있습니다!
답변
이 주제가 오래되었다는 것을 알고 있지만이 문제는 계속 발생하며 만족스럽게 해결되지 않았습니다.
$ _SESSION에 객체를 저장하거나 숨겨진 양식 필드에 저장된 데이터를 기반으로 전체 천을 재구성하거나 매번 DB에서 객체를 다시 쿼리 할 때 상태를 사용합니다. HTTP는 상태가 없지만 (거의; GET vs. PUT 참조) 웹 응용 프로그램과 관련된 거의 모든 사람이 상태를 유지해야합니다. 마치 국가를 구석 구석으로 밀어 넣는 것처럼 행동하는 것은 일종의 이론적 승리에 불과합니다. 상태는 상태입니다. 상태를 사용하면 상태 비 저장으로 인해 얻을 수있는 다양한 기술적 이점이 사라집니다. 미리 잠을 잃어야한다는 것을 알지 않는 한 잠을 잃을 일이 아닙니다.
나는 행크 게이 (Hank Gay)가 제시 한 “이중 whammy”논증에 의해받은 축복에 특히 당황 스럽다. OP는 분산되고로드 밸런싱 된 전자 상거래 시스템을 구축하고 있습니까? 내 추측은 아니요입니다. 그리고 그의 $ User 클래스 등을 직렬화하면 서버를 복구 할 수 없을 것입니다. 내 충고 : 응용 프로그램에 적합한 기술을 사용하십시오. $ _SESSION의 객체는 상식주의 사항에 따라 괜찮습니다. 앱이 갑자기 트래픽에 영향을 미치는 Amazon으로 바뀌면 다시 적응해야합니다. 인생이 다 그렇지.
답변
session_start () 호출 시간, 클래스 선언 / 정의가 이미 PHP에서 발생했거나 이미 설치된 오토로더에서 찾을 수있는 한 괜찮습니다. 그렇지 않으면 세션 저장소에서 객체를 직렬화 해제 할 수 없습니다.
답변
HTTP는 이유없는 상태 비 저장 프로토콜입니다. 세션은 HTTP에 상태를 용접합니다. 경험상 세션 상태를 사용하지 마십시오.
업데이트 : HTTP 수준에는 세션 개념이 없습니다. 서버는 클라이언트에게 고유 한 ID를 부여하고 클라이언트에게 모든 요청에 대해 다시 제출하도록 지시함으로써이를 제공합니다. 그런 다음 서버는 해당 ID를 Session 개체의 큰 해시 테이블에 대한 키로 사용합니다. 서버는 요청을받을 때마다 클라이언트가 요청과 함께 제출 한 ID를 기반으로 세션 오브젝트의 해시 테이블에서 세션 정보를 찾습니다. 이 모든 추가 작업은 확장성에 대한 두 가지 이유입니다 (HTTP가 상태 비 저장 인 큰 이유).
- Whammy One : 단일 서버가 수행 할 수있는 작업을 줄입니다.
- Whammy Two : 요청을 이전 서버로 라우팅 할 수 없기 때문에 확장이 어려워집니다. 모두 동일한 세션을 가지고 있지는 않습니다. 주어진 세션 ID를 가진 모든 요청을 동일한 서버에 고정 할 수 있습니다. 쉬운 일이 아니며 단일 장애 지점입니다 (시스템 전체가 아니라 많은 사용자를위한). 또는 클러스터의 모든 서버에서 세션 스토리지를 공유 할 수 있지만 이제 네트워크 연결 메모리, 독립형 세션 서버 등과 같이 더 복잡합니다.
모든 것을 감안할 때 세션에 더 많은 정보를 넣으면 Vinko가 지적한 것처럼 성능에 미치는 영향이 커집니다. Vinko가 지적한 것처럼 객체를 직렬화 할 수 없으면 세션이 제대로 작동하지 않습니다. 따라서 경험상 세션에 반드시 필요한 것 이상을 두지 마십시오.
@Vinko 일반적으로 보낸 응답에 추적중인 데이터를 포함시키고 클라이언트가 다시 제출하도록 (예 : 숨겨진 입력으로 데이터를 전송) 서버 저장 상태를 유지할 수 있습니다. 서버 측 상태 추적 이 실제로 필요한 경우 백업 데이터 저장소에 있어야합니다.
(Vinko는 다음과 같이 덧붙입니다. PHP는 세션 정보를 저장하기 위해 데이터베이스를 사용할 수 있으며, 클라이언트가 매번 데이터를 다시 제출하도록하면 잠재적 인 확장 성 문제가 해결 될 수 있지만, 클라이언트가 모든 것을 제어 할 수 있다는 점에주의해야합니다. 당신의 상태)
답변
- 직렬화 할 수 없거나 직렬화 할 수없는 멤버를 포함하는 오브젝트는 예상대로 $ _SESSION에서 나오지 않습니다.
- 거대한 세션으로 인해 서버에 부담이 발생합니다 (매번 비용이 많이 드는 상태를 직렬화 및 역 직렬화하면 비용이 많이 듭니다)
그 외에는 아무런 문제가 없었습니다.
답변
내 경험상, 일반적으로 일부 속성이있는 StdClass보다 복잡한 것에 대해서는 가치가 없습니다. 직렬화 해제 비용은 항상 세션 저장 식별자가 지정된 데이터베이스에서 다시 작성하는 것 이상이었습니다. 멋진 것처럼 보이지만 프로파일 링이 핵심입니다.
답변
절대적으로 필요한 경우가 아니면 상태를 사용하지 않는 것이 좋습니다. 세션을 사용하지 않고 오브젝트를 재 빌드 할 수있는 경우 수행하십시오. 웹 응용 프로그램에 상태가 있으면 응용 프로그램을 더 복잡하게 만들 수 있습니다. 모든 요청에 대해 사용자의 상태를 확인해야합니다. 물론 세션 사용을 피할 수없는 경우가 있습니다 (예 : 세션이 진행되는 동안 사용자는 로그인 상태를 유지해야 함) 웹 애플리케이션). 마지막으로 세션 개체를 가능한 한 작게 유지하여 성능에 영향을 주어 큰 개체를 직렬화 및 직렬화 해제하는 것이 좋습니다.
답변
리소스 유형 (예 : db 연결 또는 파일 포인터)은 페이지로드간에 유지되지 않으므로 보이지 않게 다시 만들어야합니다.
또한 세션 크기에 따라 저장 방법, 크기 제한 또는 대기 시간 문제가있을 수 있습니다.
