Web Dev - أين يتم تخزين حالة كائن يشبه عربة التسوق؟

أنت تبني تطبيق ويب. يجب تخزين الحالة لعنصر التسوق مثل أثناء جلسة المستخدم.

بعض الملاحظات:

  • هذه ليست سلة تسوق تمامًا ، ولكنها تشبه إلى حدٍّ أبعد مسارًا يقوم المستخدم ببنائه ... ولكننا سنستخدم كلمة عربة لحد الآن بخصوص b/c ppl ترتبط بها.
  • أنت لا تهتم بالعربات "المهجورة"
  • بعد اكتمال سلة التسوق ، سنستمر في تخزين بعض البيانات من جانب الخادم لاستردادها لاحقًا.

Where do you store that stateful object? And how?

  • الخادم (جلسة ، ديسيبل ، وما إلى ذلك؟)
  • العميل (ملفات تعريف الارتباط الرئيسية ، أو كائن JSON لملف تعريف الارتباط ، أو حقل النموذج المخفي ، وما إلى ذلك)
  • وغيرها ... </لى>

Update: It was suggested that I list the platform we're targeting - tho I'm not sure its totally necessary... but lets say the front-end is built w/ASP.NET MVC.

0
وأضاف تحرير
الآراء: 1

11 إجابة

قم بتخزينه في قاعدة البيانات.

0
وأضاف

لقد فكرت في ما تقترحه ولكن لم يكن لديك مشروع عميل حتى الآن لتجربته. الأقرب هو في الواقع قائمة التسوق التي يمكنك أن تجدها هنا ...

http://www.scottcommonsense.com/toolbox.aspx

انقر فوق قائمة فحص البقالة لفتح النافذة. إنه يستخدم ASPX ، ولكن فقط لإدارة مراجع JS الموضوعة على الصفحة. ويتم الباقي عبر AJAX باستخدام خدمات الويب.

سابقاً قمت بإنشاء موقع ASP.NET 2.0 لموقع تجاري يستخدم ملفات تعريف الارتباط الذاتية/المصادقة تلقائيًا. كل منها يوفر لك قيمة GUID والتي يمكنك استخدامها لتحديد مستخدم يرتبط بعد ذلك بالبيانات في قاعدة البيانات الخاصة بك. كنت أرغب في ملفات تعريف الارتباط لذلك يمكن للمستخدم الانتقال إلى أجهزة كمبيوتر مختلفة. العمل ، المنزل ، إلخ. أنا تجنب استخدام حقول "ملف التعريف" للاحتفاظ بكائن معقد ShoppingBasket التي كانت شائعة أثناء الوقت في كافة الكتب ASP.NET 2.0. لم أكن أرغب في التعامل مع مشكلات التسلسل "السحري" نظرًا لتغير بنية البيانات بمرور الوقت. أفضّل إدارة تغييرات مخطط DB مع البرامج النصية للتحديث/التغيير التي تمت مزامنتها مع تغييرات البرامج.

باستخدام ملفات تعريف الارتباط/auth التي تحدد المستخدم على العميل ، يمكنك استخدام عميل ASP.NET AJAX للاتصال بخدمات ويب المصادقة باستخدام بروكسيات JS التي يتم توفيرها لك كجزء من ASP.NET. تحتاج إلى تطبيق واجهة برمجة التطبيقات الخاصة بـ Membership للمصادقة على الأقل على المستخدم. يمكن باقي تطبيق الموفر إلقاء NotImplementedException بأمان. يمكنك بعد ذلك استخدام خدمات ASMX المخصصة على الويب عبر AJAX (راجع السمة ScriptReference) وتحديث الصفحات باستخدام بيانات من جانب الخادم. يمكنك التخلص تمامًا من صفحات ASPX واستخدام HTML/CSS/JS الثابت فقط إذا أردت.

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

0
وأضاف
يعجبني هذا الأسلوب ، إلا أنه من المحتمل أن أستخدم مكالمات MVC و RESTful AJAX (إرجاع JSON أو ترميز) لذا لن أحتاج إلى القلق بشأن ASMX أو ASPX.
وأضاف المؤلف stevenharman, مصدر

إذا كنت لا تهتم بالعربات المهجورة ولديك أشياء في مكان ما لشخص ما يعبث بالبيانات على جانب العميل ... أعتقد أن ملف تعريف الارتباط سيكون جيدًا - خاصة إذا كان مجرد ملف تعريف ارتباط ببيانات JSON.

0
وأضاف
نعم ، أوافق على أن ذلك يعتمد على متطلبات التطبيق فيما إذا كان هذا هو أفضل مسار أم لا.
وأضاف المؤلف Ryan Lanciaux, مصدر
تقتصر ملفات تعريف الارتباط على 4K. قد لا تكون هذه البيانات كافية ، اعتمادًا على حجم سلة التسوق.
وأضاف المؤلف 64BitBob, مصدر

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

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

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

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

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

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

0
وأضاف

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

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

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

0
وأضاف
أعتقد أن هذا اقتراح صالح - إلا أنني ربما أستخدم ملف تعريف الارتباط من جانب العميل مع بيانات JSON بدلاً من الجلسة ...
وأضاف المؤلف stevenharman, مصدر
ماذا عن حدود حجم ملفات تعريف الارتباط؟ ماذا عن تلاعب ملفات تعريف الارتباط؟ قد يكون الأمر على ما يرام بالنسبة للقائمة ، لكن بالنسبة للعربة ، يبدو الأمر خاطئًا حقًا؟ ماذا يحدث إذا قمت بتغيير مخطط البيانات؟
وأضاف المؤلف Andrew Rimmer, مصدر

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

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

0
وأضاف

Without knowing the platform I can't give a direct answer. However, since you don't care about abandoned carts, then I would differ from my colleagues here and suggest storing it on the client. Why store it in the database if you don't care if it's abandoned?
Then again, it does depend on the size of the object you're storing -- cookies have their limits after all.

Edit: Ahh, asp.net MVC? Why not use the profile system? You can enable an anonymous profile if you don't want to bother making them log in

0
وأضاف

في قاعدة البيانات مرتبطة بما تستخدمه للجلسات (جلسات عمل DB/memcache ، ملفات تعريف الارتباط الموقعة) أو إلى مستخدم تمت مصادقته.

0
وأضاف
قد لا يكون هناك حتى ديسيبل (على الأقل لا علاقة علائقية) ... :)
وأضاف المؤلف stevenharman, مصدر
تخزينها في مخزن البيانات "من جانب الخادم" :). لماذا لديك اثنين من مخازن البيانات المختلفة؟ يضيف تخزين جانب الخادم مزيدًا من المرونة والأمان.
وأضاف المؤلف Andrew Rimmer, مصدر

إذا كنت تهتم بدعم المستخدمين دون تمكين Javascript ، فستتيح لك جلسات الخادم الجانبية استخدام إعادة كتابة عنوان URL.

0
وأضاف

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

0
وأضاف
هذا ليس سيناريو نخطط لدعمه لمستخدمين مجهولين - مع أننا قد ندعمه للمستخدمين المصادقين.
وأضاف المؤلف stevenharman, مصدر

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

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

0
وأضاف