• پایان فعالیت بخشهای انجمن: امکان ایجاد موضوع یا نوشته جدید برای عموم کاربران غیرفعال شده است

سوال: چگونگی پیاده سازی مراحل خرید محصول در وب

mehrdad201

همکار بازنشسته
کاربر قدیمی پرشین تولز
تاریخ عضویت
10 سپتامبر 2005
نوشته‌ها
15,874
لایک‌ها
17,805
محل سکونت
ایران
عرض سلام و ادب خدمت همه دوستان گرامی

یه سوالی برای من پیش اومده در مورد پیاده سازی مراحل خرید یه محصول در وب سایت

موضوع این هست که یه سایتی باید طراحی بشه که هدفش فروختن یه سری کوپن تخفیف محصولات هست.
اولین و مهمترین ویژگی این کوپن ها این هست که تعداد اونها در 99 درصد موارد محدود هست. مثلا کوپن خرید لپتاپ فقط 20 عدد موجود هست.


حالا فرض رو بر این میذاریم که یک وب سایتی طراحی شده که قراره این کوپن ها در اون به فروش برسه.

من سوالم اینجاست که چطوری باید مراحل خرید اجناس (که از نظر تعداد محدود هستند) رو در یک سایت پیاده سازی کرد که مشکلی پیش نیاد.

مشکل از اون جهت که فرضا خریدار وارد سایت میشه و مراحل خرید رو اغاز میکنه .
ممکنه خرید با موفقیت به پایان برسه و خب خطایی رخ نده.
اما ممکنه طرف مبلغ رو پرداخت بکنه ولی در انتهای کار (به دلیل احتمال همزمانی خرید همون کوپن) سیستم نتونه کوپنی اختصاص بده و بگه کوپن ها تموم شده . اونوقت چه اتفاقی میفته. طرف خرید رو انجام داده و پول هم داده اما اخر کار میبینه محصولی نمونده.

از یه طرف هم ممکنه کسی بخواد خرید انجام بده اما وسط کار به هر دلیلی مثلا قطع اینترنت یا بلند شدن از پای سیستم صفحه رو به حال خودش رها کنه.

ممنون میشم دوستانی که اگاهی دارند برای بنده توضیح بدن که برای پیاده سازی فرایند خرید اجناسی که تعدادشون محدوده در یک وب سایت باید چه دقیقا چطوری عمل کرد؟
این اسکریپتهای فروشگاهی که اپشن تعداد محدود هم دارند چطوری این فرایند رو کنترل میکنند ؟

سپاسگذارم از لطف همه دوستان
 

Hasam

Registered User
تاریخ عضویت
2 اکتبر 2007
نوشته‌ها
665
لایک‌ها
159
محل سکونت
flynic.ir
سلام

اگر فرآیند خرید رو با مراحل زیر در نظر بگیریم:

1. افزودن به سبد خرید
2. اتصال به بانک و پرداخت
3. ثبت سفارش با موفقیت (یا عدم ثبت در صورت عدم پرداخت یا انصراف)

می‌تونید با یک فرآیند رزرو کردن این مشکل رو پوشش بدید، مثلاً:

1. افزودن به سبد خرید
2. رزرو آن تعداد کالا (یعنی ثبت موقت آن تعداد کالا برای کاربر جاری، در این صورت کاربران دیگه نمی‌تونند این محصول -یا این تعداد محصول- رو سفارش بدهند)
3. اتصال به بانک و پرداخت
4. در صورت پرداخت موفق که همه چیز مشخص هست، اما در صورت پرداخت ناموفق تعداد رزرو شده به تعداد اقلام فروخته نشده اضافه شود.

با این روش لازم هست چک بشه که مثلاً اگر تکلیف رزروی تا 5 دقیقه مشخص نشد، به لیست اقلام بازگردانده شود و نشست مربوطه نابود (!) شود.
 

mehrdad201

همکار بازنشسته
کاربر قدیمی پرشین تولز
تاریخ عضویت
10 سپتامبر 2005
نوشته‌ها
15,874
لایک‌ها
17,805
محل سکونت
ایران
سلام

اگر فرآیند خرید رو با مراحل زیر در نظر بگیریم:

1. افزودن به سبد خرید
2. اتصال به بانک و پرداخت
3. ثبت سفارش با موفقیت (یا عدم ثبت در صورت عدم پرداخت یا انصراف)

می‌تونید با یک فرآیند رزرو کردن این مشکل رو پوشش بدید، مثلاً:

1. افزودن به سبد خرید
2. رزرو آن تعداد کالا (یعنی ثبت موقت آن تعداد کالا برای کاربر جاری، در این صورت کاربران دیگه نمی‌تونند این محصول -یا این تعداد محصول- رو سفارش بدهند)
3. اتصال به بانک و پرداخت
4. در صورت پرداخت موفق که همه چیز مشخص هست، اما در صورت پرداخت ناموفق تعداد رزرو شده به تعداد اقلام فروخته نشده اضافه شود.

با این روش لازم هست چک بشه که مثلاً اگر تکلیف رزروی تا 5 دقیقه مشخص نشد، به لیست اقلام بازگردانده شود و نشست مربوطه نابود (!) شود.

بله این روشی هست که به ذهنم میرسه. اما مساله اینجاست که اگه یه یوزر بیکار بیاد 5 تا صفحه جدا باز کنه و خرید بزنه یا اینکه یکی برنامه ربات بنویسه که بیاد خرید الکی انجام بده (یعنی خرید بزنه اما تا مرحله پرداخت بره و پول نده) اونوقت این رزرو کردنها باعث مشکل نمیشه.

اونطوری همش موجودی کوپن های باقیمونده غیر واقعی هست !! و فکر کنید در هر 10 15 دقیقه این ربات ها این فرایند ازار و اذیت رو هی تکرار کنند.
 

Hasam

Registered User
تاریخ عضویت
2 اکتبر 2007
نوشته‌ها
665
لایک‌ها
159
محل سکونت
flynic.ir
بله این روشی هست که به ذهنم میرسه. اما مساله اینجاست که اگه یه یوزر بیکار بیاد 5 تا صفحه جدا باز کنه و خرید بزنه یا اینکه یکی برنامه ربات بنویسه که بیاد خرید الکی انجام بده (یعنی خرید بزنه اما تا مرحله پرداخت بره و پول نده) اونوقت این رزرو کردنها باعث مشکل نمیشه.

اونطوری همش موجودی کوپن های باقیمونده غیر واقعی هست !! و فکر کنید در هر 10 15 دقیقه این ربات ها این فرایند ازار و اذیت رو هی تکرار کنند.

خیلی خوب هست که شما به همه‌ی این مشکلات فکر می‌کنید، اما باید ببینید واقعاً نوشتن کد برای این رخدادها ضروری هست یا نه.

برای مساله‌ی "یوزر بیکار" میتونید از سشن استفاده کنید و برای هر آی‌پی یک سبد خرید یکتا در نظر بگیری. یعنی با هر مرورگری از اون آی‌پی از سایت بازدید بشه، فقط و فقط یک سبد خرید و محتوا به اون نشون داده میشه.

برای مورد "یعنی خرید بزنه اما تا مرحله پرداخت بره و پول نده"، طبق چیزی که در بند آخر در پست قبلی گفتم می‌تونید یک schedule یا cron تنظیم کنید که هر چند ثانیه (مثلا 60 تا 120 ثانیه)، خرید‌هایی که تا مرحله‌ی پرداخت رفته اما پاسخی دریافت نشده رو حذف کنه و مقادیر رزرو شده رو به لیست بازگردونه.

و در پایان "اگر کسی رباتی بنویسد که هر 10 15 ..." اینجا می‌تونید یک کد برای بَن کردن آی‌پی‌های مزاحم داشته باشید که اگر در دقیقه بیش از n ریکوئست داشتن، برای x ثانیه دسترسی اون به سایت محدود بشه.

---
مثلی هست که میگه سری که درد نمیکنه رو دستمال نمی‌بندند. اول باید دید داشتن چنین امکانات "واقعا" ضروری هست یا خیر.
اگر این پروژه‌ی شخصی من بود، ابتدا پایه‌ی سیستم رو کار می‌کردم و در طول اجرای پروژه این ویژگی‌ها رو به اون اضافه می‌کردم. (شاید در آینده وجود چنین امکاناتی ضروری باشند).
 

mehrdad201

همکار بازنشسته
کاربر قدیمی پرشین تولز
تاریخ عضویت
10 سپتامبر 2005
نوشته‌ها
15,874
لایک‌ها
17,805
محل سکونت
ایران
خیلی خوب هست که شما به همه‌ی این مشکلات فکر می‌کنید، اما باید ببینید واقعاً نوشتن کد برای این رخدادها ضروری هست یا نه.

برای مساله‌ی "یوزر بیکار" میتونید از سشن استفاده کنید و برای هر آی‌پی یک سبد خرید یکتا در نظر بگیری. یعنی با هر مرورگری از اون آی‌پی از سایت بازدید بشه، فقط و فقط یک سبد خرید و محتوا به اون نشون داده میشه.

برای مورد "یعنی خرید بزنه اما تا مرحله پرداخت بره و پول نده"، طبق چیزی که در بند آخر در پست قبلی گفتم می‌تونید یک schedule یا cron تنظیم کنید که هر چند ثانیه (مثلا 60 تا 120 ثانیه)، خرید‌هایی که تا مرحله‌ی پرداخت رفته اما پاسخی دریافت نشده رو حذف کنه و مقادیر رزرو شده رو به لیست بازگردونه.

و در پایان "اگر کسی رباتی بنویسد که هر 10 15 ..." اینجا می‌تونید یک کد برای بَن کردن آی‌پی‌های مزاحم داشته باشید که اگر در دقیقه بیش از n ریکوئست داشتن، برای x ثانیه دسترسی اون به سایت محدود بشه.

---
مثلی هست که میگه سری که درد نمیکنه رو دستمال نمی‌بندند. اول باید دید داشتن چنین امکانات "واقعا" ضروری هست یا خیر.
اگر این پروژه‌ی شخصی من بود، ابتدا پایه‌ی سیستم رو کار می‌کردم و در طول اجرای پروژه این ویژگی‌ها رو به اون اضافه می‌کردم. (شاید در آینده وجود چنین امکاناتی ضروری باشند).

ممنونم. البته صحبت شما درست هست. من راستش چون تجربه ای در زمینه طراحی شاپینگ کارت و فرایند خرید نداشتم تمام سوالاتی که به ذهنم اومده رو مطرح کردم. درسته احتمال این رویدادها شاید نزدیک به صفر باشه اما به هر حال باید همیشه انتظار شرایط پیش بینی نشده رو داشت.

من سیستم رو میخوام با دروپال پیاده کنم. بنابراین باید ببینم چطور میتونم این فرایند رو در این سیستم پیاده کنم. حالا باز هم تحقیق و بررسی میکنم ببینم چی میشه.

اگه منابعی در این زمینه میشناسید ممنون میشم راهنماییم کنید.
 
بالا