www.dntips.ir
مطالب
نویسندگان
گروه‌های مطالب
نقشه‌های راه
دوره‌ها
اشتراک‌ها
پرسش‌ها
عنوان:

‫ارسال چند شناسه برای کاربر منطقی است؟


نویسنده: هادی مزارعی
تاریخ: ۱۴۰۴/۰۵/۱۴ ۱۳:۴۹
آدرس: www.dntips.ir
سناریو:

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

سوال:
آیا ارسال تمام شناسه‌های مربوط به محصول که قرار است برای عملیات استفاده شوند در همان مرحله ارسال لیست به کاربر پیشنها می‌شود؟

توضیحات:
  1. در حال حاضر تنها شناسه محصول بین کاربر و سرور ارسال و دریافت می‌شود و هندلر می‌بایست شناسه‌های دیگر را خودش واکشی کند.
  2. در حقیقت پیاده‌سازی برمبنای تبادل حداقل شناسه بین سرور و کاربر بوده که ضمن در معرض قرار دادن کمترین داده‌ها درسمت کاربر، ممکن است کاربر با همه محصولات کاری نداشته باشد و یا اصلا دستوری را اجرا نکند ولی ارسال تمام شناسه‌ها باعث می‌شد بانک اطلاعاتی داده‌های بیشتری را پردازش و به سمت کاربر ارسال کند. لذا در پیاده‌سازی جاری فقط برای محصول جاری، سایر شناسه‌ها از بانک دریافت خواهند شد.
مطالب مشابه

نظرات

  • وحید نصیری در ۱۴۰۴/۰۵/۱۴ ۱۳:۵۵
    رویکرد فعلی شما مبنی بر ارسال تنها شناسه محصول (GUID) به کاربر و واکشی سایر شناسه‌ها در سمت سرور، رویکردی منطقی و توصیه شده است. این روش مزایای مهمی از جمله امنیت، کارایی و حفظ حریم خصوصی داده‌ها را به همراه دارد.

    مزایای رویکرد فعلی شما

    • کاهش حجم داده‌های ارسالی: با ارسال فقط شناسه محصول، حجم داده‌های ارسالی به سمت کاربر به حداقل می‌رسد. این امر به خصوص در زمان بارگذاری لیست‌های طولانی محصولات، باعث افزایش سرعت و کاهش مصرف پهنای باند می‌شود.
    • امنیت بیشتر: ارسال تعداد کمتری از شناسه‌ها، به معنی در معرض قرار دادن داده‌های حساس کمتر است. اگر کاربر فقط شناسه محصول را در اختیار داشته باشد، امکان دسترسی یا دستکاری ناخواسته به سایر شناسه‌ها و جداول مرتبط (که ممکن است شامل اطلاعات حساس باشند) کاهش می‌یابد.
    • پرهیز از واکشی غیرضروری: همانطور که اشاره کردید، اگر کاربر هیچ عملیاتی انجام ندهد، نیازی به واکشی و پردازش اطلاعات اضافی از پایگاه داده نخواهد بود. این بهینه‌سازی، بار روی سرور و پایگاه داده را کاهش می‌دهد.
    • جداسازی منطقی: این رویکرد به جداسازی وظایف (separation of concerns) کمک می‌کند. وظیفه نمایش لیست به کاربر با وظیفه انجام عملیات روی یک محصول مشخص، از هم جدا می‌شوند. کاربر فقط اطلاعات لازم برای انتخاب یک آیتم را دریافت می‌کند و منطق پیچیده عملیات در سمت سرور محفوظ می‌ماند.

    معایب ارسال چند شناسه به کاربر (رویکرد جایگزین)

    • افزایش حجم داده: ارسال تمام شناسه‌ها از همان ابتدا، باعث افزایش قابل توجه حجم پاسخ (response) سرور می‌شود. این مسئله می‌تواند سرعت بارگذاری را کاهش داده و تجربه کاربری را تحت تاثیر قرار دهد.
    • افزایش ریسک امنیتی: با قرار دادن شناسه‌های مرتبط با جداول مختلف در سمت کاربر، ریسک حملات احتمالی (مانند SQL Injection یا دستکاری داده‌ها) افزایش می‌یابد. اگر یک مهاجم به این شناسه‌ها دسترسی پیدا کند، می‌تواند تلاش کند تا با استفاده از آنها به سایر بخش‌های سیستم شما نفوذ کند.
    • پردازش و واکشی غیرضروری: سرور مجبور است برای هر درخواستی که لیست محصولات را می‌فرستد، تمام شناسه‌های مرتبط با هر محصول را واکشی کند، حتی اگر کاربر هرگز از آنها استفاده نکند.

    نتیجه‌گیری و پیشنهاد

    رویکرد فعلی شما، بهترین راهکار است. این روش ضمن حفظ امنیت و کارایی، از بارگذاری غیرضروری روی سرور و پایگاه داده جلوگیری می‌کند. در نهایت، تصمیم‌گیری برای ارسال داده به کاربر باید بر اساس اصل "حداقل اطلاعات لازم" (Principle of Least Privilege) باشد. به کاربر فقط داده‌هایی را بدهید که برای انجام وظیفه فعلی‌اش به آنها نیاز دارد. در این سناریو، کاربر فقط به شناسه محصول برای انتخاب و ارسال درخواست نیاز دارد و باقی اطلاعات باید در سمت سرور پردازش شوند.