صفحه بندی در ASP.NET Core Web API
شناسه پست: 2431
بازدید: 1552

در این مقاله، میخواهیم یاد بگیریم که چطور صفحه بندی (paging) را در ASP.NET Core Web API انجام دهیم. صفحه بندی، یکی از مهمترین مفاهیم در RESTful API ها است.

در واقع، زمانیکه ما یک کوئری به سمت API میفرستیم، در پاسخ نمیخواهیم که یک کالکشن از منابع را برگردانیم. این میتواند در performance برنامه، مشکلاتی ایجاد کند. به هیچ وجه برای API های public یا private، راهکار بهینه ای نیست. این می تواند در موارد شدید باعث کندی شدید و حتی خرابی برنامه نیز شود.

اگر میخواهید ما را در این مقاله همراهی کنید، میتوانید از نقطه شروع پروژه استفاده کنید و اگر میخواهید solution نهایی را بگیرید یا اگر جایی در پروژه گیر کرده اید میتوانید نقطه انتهایی پروژه را ببینید.

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

بنابراین، ببینیم دقیقا در مورد چه چیزی قرار است در این مقاله صحبت کنیم:

شروع کنیم.

صفحه بندی چیست؟

صفحه بندی یعنی دریافت نتایج از یک API به طور جزء به جزء. تصور کنید که شما میلیونها رکورد در دیتابیس دارید و برنامه شما میخواهد تمام آنها را در یک زمان برگرداند.

نه تنها این روش برای برگرداندن نتایج، بسیار ناکارآمد است ، بلکه همچنین می تواند تأثیرات مخربی بر روی خود برنامه یا سخت افزاری که آن را اجرا می کند داشته باشد. علاوه بر این، هر کلاینت، منابع حافظه محدودی دارد و نیاز است که بر روی تعداد نتایج برگردانده شده محدودیت اعمال شود.

بنابراین ، ما برای جلوگیری از این عواقب به راهی نیاز داریم که بتوانیم تعداد معینی از نتایج را به کلاینت برگردانیم.

ببینیم چطور میتوانیم این کار را انجام دهیم.

پیاده سازی اولیه

قبل از اینکه تغییری بر روی سورس انجام دهیم، اجازه دهید بررسی کنیم که ساده ترین حالت پیاده سازی به چه صورت است و چطور ممکن است که شما در هر پروژه ای، آن را انجام دهید.

در سناریو ما، ما OwnerController را داریم که شامل تمام اکشنهای لازم برای موجودیت Owner میباشد.

یک مورد ویژه که قابل توجه است و باید آن را تغییر دهیم، اکشن ()GetOwners میباشد:

که ()GetOwners را از OwnerRepository فراخوانی میکند:

متد ()FindAll، فقط یک متد از کلاس Base Repository است که کل مجموعه owner ها را برمیگرداند.

همانطور که میبینید، این یک اقدام بی چون و چرا است. به این معنی که تمام owner ها را از دیتابیس به ترتیب نام برمیگرداند.

و این فقط همین کار را انجام میدهد.

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

آنوقت ما با کوئریهای زمانبر که مقدار زیادی داده برمیگرداند روبه رو میشویم.

بهترین حالت این است که شما کار خود را با تعداد کمی از owner ها شروع کنید که با گذشت زمان به آرامی افزایش می یابد سپس می توانید کم کم متوجه کاهش عملکرد در برنامه شوید. سناریوهای دیگر برای برنامه و دستگاه های شما غیرکارآمد هستند (تصور کنید میزبانی در فضای ابری باشد و حافظه کش مناسب نداشته باشد).

بنابراین با این اوصاف، این متد را برای حمایت از صفحه بندی تغییر میدهیم.

پیاده سازی صفحه بندی

توجه داشته باشید، ما قصد نداریم منطق base repository را تغییر دهیم یا هیچ business logic ای را در کنترلر پیاده سازی کنیم.

چیزی که میخواهیم بدست بیاوریم به این صورت است: https://localhost:5001/api/owners?pageNumber=2&pageSize=2. این باید دو owner از دسته دوم از owner ها را که در دیتابیس داریم را برگرداند.

همچنین میخواهیم API مان را محدود کنیم که تمام owner ها را با هم برنگرداند حتی زمانیکه کسی https://localhost:5001/api/owners را فراخوانی میکند.

حالا کارمان را با تغییر کنترلر شروع میکنیم:

چند نکته که باید در اینجا توجه داشته باشید:

  • ما داریم متد GetOwners را از OwnerRepository فراخوانی میکنیم که هنوز وجود ندارد، اما به زودی آن را پیاده سازی میکنیم.
  • ما داریم از [FromQuery] استفاده میکنیم که دلالت بر این دارد که ما میخواهیم از query parameter ها برای مشخص کردن اینکه کدام صفحه و چه تعداد owner را داریم مورد درخواست قرار میدهیم استفاده کنیم.
  • کلاس OwnerParameters دربرگیرنده پارامترهای مورد نظر است.

بنابراین چون کلاس OwnerParameters را داریم به عنوان یک آرگومان به کنترلرمان پاس میدهیم باید در واقع آن را ایجاد کنیم. آن را در پوشه Models در پروژه Entities ایجاد میکنیم:

ما داریم از مقدار ثابت maxPageSize برای محدود کردن API مان به حداکثر 50 owner استفاده میکنیم. ما دو خصوصیت public داریم – PageNumber و PageSize. اگر این دو خصوصیت توسط کسی که کوئری را فراخوانی میکند تعیین نشود، آنگاه PageNumber با 1 و PageSize با 10 ست میشود.

حال مهمترین قسمت یعنی منطق repository را پیاده سازی میکنیم.

ما باید متد ()GetOwners در اینترفیس IOwnerRepository و کلاس OwnerRepository را توسعه دهیم:

و logic:

خب، راحترین راه برای تشریح کد، ذکر یک مثال میباشد.

فرض کنید که میخواهیم نتایج را از صفحه سوم وبسایتمان و به تعداد 20 تا بدست آوریم. این به این معنی است که میخواهیم ((3 – 1) * 20) = 40 نتیجه اول را رد کنیم و سپس 20 تای بعدی را گرفته و به caller برگردانیم.

آیا قابل درک است؟

تست solution

حالا در دیتابیسمان، فقط چند owner داریم. بنابراین اجازه بدید این Api زیر را فراخوانی کنیم:

این باید دومین زیرمجموعه از  owner ها را به تعداد 2  owner برگرداند:

اگر این همان چیزی است که شما هم دریافت کردید، پس کارتان را درست انجام داده اید.

حالا چه کاری میتوانیم برای بهبود این solution انجام دهیم؟

بهبود Solution

از آنجا که ما فقط زیرمجموعه ای از نتایج را به caller بر می گردانیم ، ممکن است به جای List، یک PagedList داشته باشیم.

PagedList از کلاس List ارث بری میکند و ویژگیهای دیگری نیز به آن اضافه میکنیم. همچنین میتوانیم منطق skip/take را به  PagedList انتقال دهیم، زیرا این منطقیتر به نظر میرسد.

پس آن را پیاده سازی میکنیم.

پیاده سازی کلاس PagedList

ما نمیخواهیم منطق skip/take در repository مان پیاده سازی شود. پس یک کلاس برای آن ایجاد میکنیم:

همانطور که میبینید، ما منطق skip/take را به متد static داخل کلاس PagedList انتقال داده ایم. ما چند ویژگی دیگر اضافه کرده ایم که به عنوان metadata برای response مان مفید خواهد بود.

true ،HasPrevious است اگر CurrentPage بزرگتر از 1 باشد و اگر CurrentPage نیز از total pages(تعداد کل صفحات) کوچکتر باشد، مقدار true ،HasNext میشود. همچنین TotalPages با تقسیم تعداد item ها بر page size و گرد شدن آن به عدد بزرگتر محاسبه میشود، زیرا تعداد 1 صفحه حتما باید وجود داشته باشد حتی اگر یک item فقط موجود باشد.

حال که این جریان را برای خودمان شفاف سازی کردیم، OwnerRepository و OwnerController را متناسب با آن تغییر میدهیم.

اول باید repo را تغییر دهیم (فراموش نکنید که اینترفیس را نیز تغییر دهید):

و سپس کنترلر:

حالا اگر این درخواست https://localhost:5001/api/owners?pageNumber=2&pageSize=2 که پیشتر فرستادیم را مجددا بفرستیم، دقیقا همان نتیجه را دریافت میکنیم:

اما اینبار، کمی اطلاعات مفید دیگری در X-Pagination response header نیز داریم:

X-Pagination response header

همانطور که میبینید، کل metadata ما اینجاست. ما میتوانیم هنگام ایجاد صفحه بندی در frontend، از این اطلاعات استفاده کنیم. می توانید با درخواست های مختلف بازی کنید تا ببینید که در سناریوهای دیگر چگونه کار می کند.

یک چیز دیگر وجود دارد که می توانیم انجام دهیم تا این solution ما عمومی تر شود. ما کلاس OwnerParameters را داریم، اما اگر بخواهیم این solution را در AccountController مان میز استفاده کنیم چاره چیست؟ پارامترهایی که ما به سمت Account controller میفرستیم ممکن است متفاوت باشد. شاید نه برای صفحه بندی، اما بعدا یک سری پارامترهای مختلف را به سمت آن میفرستیم و باید parameter classe ها را از هم تفکیک کنیم.

ببینیم چطور آن را بهبود میدهیم.

ایجاد یک کلاس پارامتر والد

اول، یک کلاس abstract QueryStringParameters ایجاد میکنیم. ما از این کلاس برای پیاده سازی ویژگیهای مشترک برای تمام کلاس پارامترهایی که پیاده سازی میکنیم استفاده میکنیم و چون OwnerController و AccountController را داریم به این معنی است که باید کلاسهای OwnerParameters و AccountParameters را ایجاد کنیم.

با تعریف کلاس QueryStringParameters داخل پوشه Models در پروژه Entities شروع میکنیم:

ما همچنین منطق صفحه بندی خود را به داخل این کلاس منتقل کرده ایم زیرا این برای هر موجودیتی که بخواهیم از طریق repository برگردانیم معتبر خواهد بود.

اول باید کلاس AccountParameters را ایجاد کنیم و سپس کلاس QueryStringParameters را در هردو کلاسهای OwnerParameters و AccountParameters ارث بری کنیم.

logic را از OwnerParameters حذف کنید و از QueryStringParameters ارث بری کنید:

و کلاس AccountParameters را داخل پوشه Models نیز ایجاد کنید:

اکنون ، این کلاس ها اکنون کمی خالی به نظر می رسند ، اما به زودی آنها را با سایر پارامترهای مفید تکمیل خواهیم کرد و خواهیم دید که مزیت واقعی چیست. در حال حاضر، این مهم است که راهی برای ارسال یک مجموع متفاوت از پارامترها برای AccountController و OwnerController داشته باشیم.

حالا همچین solution ای را داخل AccountController مان نیز میتوانیم انجام دهیم:

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

همه چیز در مورد صفحه بندی، همین است.

نتیجه گیری

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

solution ای که ما پیاده سازی کردیم بی عیب و نقص نیست، به هیچ وجه، اما شما نکته را گرفتید. ما قسمتهای مختلف مکانیسم صفحه بندی را از هم جدا کردیم و می توانیم حتی فراتر برویم و آن را کمی عمومی تر کنیم. اما شما میتوانید آن را به عنوان یک تمرین انجام دهید و آن را در پروژه خودتان پیاده سازی نمایید.

در این مقاله، ما موضوعات زیر را پوشش داده ایم:

  • آسانترین راه پیاده سازی صفحه بندی در ASP.NET Core Web API
  • تست solution در یک سناریوی واقعی
  • بهبود solution با معرفی موجودیت PagedList و جداسازی پارامترهایمان برای کنترلرهای مختلف

امیدوارم شما این مقاله را دوست داشته باشید و چیز جدید و مفیدی را از آن یاد گرفته باشید. در مقاله بعدی، ما فیلترینگ را پوشش میدهیم.

نویسنده

امید عباسی
من امید عباسی هستم. سالهاست که در زمینه برنامه نویسی با تکنولوژی دات نت فعالیت میکنم و عاشق این هستم که تجربیات و دانش خودم را در این زمینه با دیگران به اشتراک بزارم. خیلی دوست دارم که نظر و انتقاد خودتون رو در مورد این نوشته برای من بنویسید تا بتونم در آینده، مطالب بهتر و ارزشمندتری را برای شما فراهم کنم. در صورت داشتن هرگونه سوال هم در قسمت دیدگاه ها میتونید با بنده در ارتباط باشید