بي أتش بي:تخزين "الكائنات" داخل $_SESSION

Question

لقد اكتشفت للتو أنني أستطيع فعل ذلك تخزين الكائنات في $_SESSION وأجده رائعًا جدًا لأنه عندما أنتقل إلى صفحة أخرى لا يزال لدي الشيء الخاص بي.الآن قبل أن أبدأ في استخدام هذا الأسلوب، أود أن أعرف ما إذا كانت فكرة جيدة حقًا أم أنها موجودة بالفعل المزالق المحتملة متضمن.

أعلم أنه إذا كان لدي نقطة دخول واحدة فلن أحتاج إلى القيام بذلك ولكنني لم أصل إلى هناك بعد، لذا ليس لدي نقطة دخول واحدة وأود حقًا الاحتفاظ بأشياءي لأنني لا أملك ذلك. لا أفقد حالتي من هذا القبيل.(لقد قرأت الآن أيضًا أنه يجب علي برمجة المواقع عديمة الجنسية ولكني لا أفهم هذا المفهوم بعد.)

لذا باختصار:هل من المقبول تخزين الكائنات في الجلسة، هل هناك أي مشاكل في ذلك؟

---

يحرر:

ملخص مؤقت:الآن أفهم أنه من المحتمل من الأفضل إعادة إنشائها الكائن حتى لو كان يتضمن الاستعلام عن قاعدة البيانات مرة أخرى.

ربما يمكن الحصول على مزيد من الإجابات تفصيل هذا الجانب اكثر قليلا!

Answer 1

أعلم أن هذا الموضوع قديم، لكن هذه المشكلة تتكرر باستمرار ولم تتم معالجتها بما يرضيني:

سواء قمت بحفظ الكائنات في $_SESSION، أو إعادة بنائها بالكامل استنادًا إلى البيانات المخزنة في حقول النماذج المخفية، أو إعادة الاستعلام عنها من قاعدة البيانات في كل مرة، فأنت تستخدم الحالة.HTTP عديم الحالة (أكثر أو أقل؛ولكن انظر الحصول على مقابل.PUT) ولكن كل ما يهتم به أي شخص تقريبًا باستخدام تطبيق الويب يتطلب الحفاظ على الحالة في مكان ما.إن التصرف وكأن دفع الدولة إلى الزوايا والأركان يرقى إلى نوع من الفوز النظري هو أمر خاطئ تمامًا.الدولة هي الدولة.إذا كنت تستخدم الحالة، فستفقد المزايا التقنية المتنوعة التي اكتسبتها من خلال كونك عديم الجنسية.هذا ليس شيئًا يفقدك النوم إلا إذا كنت تعلم مسبقًا أنك يجب أن تفقد النوم بسببه.

لقد شعرت بالذهول بشكل خاص من النعمة التي تلقتها حجج "الضربة المزدوجة" التي قدمها هانك جاي.هل يقوم البروتوكول الاختياري ببناء نظام تجارة إلكترونية موزع ومتوازن التحميل؟تخميني لا.وسأفترض أيضًا أن إجراء تسلسل لفئته $User، أو أي شيء آخر، لن يؤدي إلى شل خادمه بشكل لا يمكن إصلاحه.نصيحتي:استخدم التقنيات المناسبة لتطبيقك.الكائنات الموجودة في $_SESSION جيدة، وتخضع للاحتياطات المنطقية.إذا تحول تطبيقك فجأة إلى شيء ينافس أمازون في عدد الزيارات المقدمة، فستحتاج إلى إعادة التكيف.هكذا الحياة.

Answer 2

لا بأس طالما أنه بحلول وقت إجراء استدعاء session_start()، يكون تعريف/تعريف الفئة قد تمت مواجهته بالفعل بواسطة PHP أو يمكن العثور عليه بواسطة أداة التحميل التلقائي المثبتة بالفعل.وإلا فلن يتمكن من إلغاء تسلسل الكائن من مخزن الجلسة.

Answer 3

HTTP هو بروتوكول عديم الحالة لسبب ما.يتم لحام الجلسات على HTTP.كقاعدة عامة، تجنب استخدام حالة الجلسة.

تحديث:لا يوجد مفهوم للجلسة على مستوى HTTP؛توفر الخوادم ذلك من خلال منح العميل معرفًا فريدًا وإخبار العميل بإعادة إرساله عند كل طلب.ثم يستخدم الخادم هذا المعرف كمفتاح في جدول تجزئة كبير لكائنات الجلسة.عندما يحصل الخادم على طلب، فإنه يبحث عن معلومات الجلسة من جدول تجزئة كائنات الجلسة بناءً على المعرف الذي أرسله العميل مع الطلب.كل هذا العمل الإضافي يمثل ضربة مزدوجة فيما يتعلق بقابلية التوسع (وهو سبب كبير لأن HTTP عديم الحالة).

• الضربة الواحدة:إنه يقلل من العمل الذي يمكن لخادم واحد القيام به.
• الضربة الثانية:وهذا يزيد من صعوبة التوسع لأنه لا يمكنك الآن توجيه الطلب إلى أي خادم قديم - فليس لديهم جميعًا نفس الجلسة.يمكنك تثبيت جميع الطلبات بمعرف جلسة محدد على نفس الخادم.هذا ليس بالأمر السهل، وهو يمثل نقطة فشل واحدة (ليس للنظام ككل، ولكن لقطاعات كبيرة من المستخدمين).أو يمكنك مشاركة تخزين الجلسة عبر كافة الخوادم في المجموعة، ولكن الآن لديك المزيد من التعقيد:الذاكرة المتصلة بالشبكة، وخادم جلسة مستقل، وما إلى ذلك.

بالنظر إلى كل ذلك، كلما زادت المعلومات التي تقدمها في الجلسة، زاد التأثير على الأداء (كما يشير فينكو).كما يشير Vinko أيضًا، إذا لم يكن الكائن الخاص بك قابلاً للتسلسل، فسوف تتصرف الجلسة بشكل سيء.لذا، كقاعدة عامة، تجنب وضع أكثر من اللازم في الجلسة.

@Vinko يمكنك عادةً التغلب على حالة مخزن الخادم عن طريق تضمين البيانات التي تتتبعها في الرد الذي ترسله مرة أخرى ومطالبة العميل بإعادة إرسالها، على سبيل المثال، إرسال البيانات إلى الأسفل في إدخال مخفي.اذا أنت حقًا تحتاج إلى تتبع الحالة من جانب الخادم، فمن المحتمل أن تكون في مخزن البيانات الداعم لديك.

(يضيف فينكو:يمكن لـ PHP استخدام قاعدة بيانات لتخزين معلومات الجلسة، وقد يؤدي قيام العميل بإعادة إرسال البيانات في كل مرة إلى حل مشكلات قابلية التوسع المحتملة، ولكنه يفتح مجموعة كبيرة من المشكلات الأمنية التي يجب عليك الانتباه إليها الآن بعد أن أصبح العميل يتحكم في كل حالتك)

Answer 4

• الكائنات التي لا يمكن إجراء تسلسل لها (أو التي تحتوي على أعضاء غير قابلين للتسلسل) لن تخرج من $_SESSION كما تتوقع
• تضع الجلسات الضخمة عبئًا على الخادم (إجراء تسلسل وإلغاء تسلسل megs للحالة في كل مرة أمر مكلف)

بخلاف ذلك لم أر أي مشاكل.

Answer 5

في تجربتي، لا يستحق الأمر عمومًا أي شيء أكثر تعقيدًا من StdClass مع بعض الخصائص.لقد كانت تكلفة إلغاء التسلسل دائمًا أكثر من مجرد إعادة الإنشاء من قاعدة بيانات باستخدام معرف مخزن في الجلسة.يبدو الأمر رائعًا، ولكن (كما هو الحال دائمًا)، فإن التنميط هو المفتاح.

Answer 6

أود أن أقترح عدم استخدام الحالة إلا إذا كنت في حاجة إليها بشدة.إذا كان بإمكانك إعادة بناء الكائن دون استخدام الجلسات، فافعل ذلك.إن وجود حالات في تطبيق الويب الخاص بك يجعل إنشاء التطبيق أكثر تعقيدًا، ولكل طلب يجب عليك معرفة الحالة التي يوجد بها المستخدم.بالطبع هناك أوقات لا يمكنك فيها تجنب استخدام الجلسة (على سبيل المثال:يجب أن يظل المستخدم يقوم بتسجيل الدخول أثناء جلسته على تطبيق الويب).أخيرًا، أود أن أقترح إبقاء كائن الجلسة صغيرًا قدر الإمكان لأنه يؤثر على الأداء في إجراء تسلسل للكائنات الكبيرة وإلغاء تسلسلها.

Answer 7

يجب أن تتذكر أن أنواع الموارد (مثل اتصالات قاعدة البيانات أو مؤشرات الملفات) لن تستمر بين عمليات تحميل الصفحة، وستحتاج إلى إعادة إنشائها بشكل غير مرئي.

ضع في اعتبارك أيضًا حجم الجلسة، اعتمادًا على كيفية تخزينها، قد تكون لديك قيود على الحجم أو مشكلات في زمن الاستجابة.

Answer 8

أود أيضًا أن أتحدث عن ترقية مكتبات البرامج - لقد قمنا بترقية برنامجنا وكان الإصدار القديم يحتوي على كائنات في جلسة مع أسماء فئات برنامج V1، وكان البرنامج الجديد يتعطل عندما حاول إنشاء الكائنات التي كانت في الجلسة - مثل V2 لم يعد البرنامج يستخدم نفس الفئات بعد الآن، ولم يتمكن من العثور عليها.كان علينا أن نضع بعض رموز الإصلاح لاكتشاف كائنات الجلسة، وحذف الجلسة إذا وجدت، وإعادة تحميل الصفحة.كان الألم الأكبر في البداية هو إعادة إنشاء هذا الخطأ عندما تم الإبلاغ عنه لأول مرة (كل شيء مألوف جدًا، "حسنًا، إنه يعمل بالنسبة لي") لأنه يؤثر فقط على الأشخاص الذين يدخلون ويخرجون من الأنظمة القديمة والجديدة مؤخرًا - ومع ذلك، جيد لقد عثرنا على الوظيفة قبل إطلاقها حيث كان من المؤكد أن جميع مستخدمينا كان لديهم متغيرات الجلسة القديمة في جلساتهم وكان من المحتمل أن يتعطلوا للجميع، وكان من الممكن أن يكون الإطلاق سيئًا :)

على أي حال، كما تقترح في تعديلك، أعتقد أيضًا أنه من الأفضل إعادة إنشاء الكائن.لذلك ربما يكون مجرد تخزين المعرف ثم سحب الكائن من قاعدة البيانات عند كل طلب، أفضل/أكثر أمانًا.