https://virgool.io/feed/@kaafochino 0x4b6172696d50617a6f6b69 fa 2026-04-14 19:10:19 https://files.virgool.io/upload/users/39097/avatar/yb8dAM.jpeg?height=120&width=120 https://virgool.io/@kaafochino https://virgool.io/@kaafochino/%D8%AF%D8%B1-%D8%A8%D8%A7%D8%A8-%D8%AA%D8%BA%DB%8C%DB%8C%D8%B1-%D8%A2%D8%AF%D8%B1%D8%B3-%D8%B5%D9%81%D8%AD%D9%87-%D9%88-301-%D8%B1%DB%8C%D8%AF%D8%A7%DB%8C%D8%B1%DA%A9%D8%AA-%DB%8C%D8%A7-%D8%A8%D8%B1%D9%88-%DA%A9%D9%87-%D8%B1%D9%81%D8%AA%D9%87-%D8%A7%DB%8C-%D8%A8%D8%B1%D9%88-%DB%8C%D8%A7%D8%B1%DB%8C-%D8%AF%DA%AF%D8%B1-%D8%A8%DA%AF%DB%8C%D8%B1-sotkoova92it یکم: هویت به جهت وحدت هر چیزی اطلاق می‌شود.آدرس کنونیکال (Canonical url) به مثابه‌ هویت هر صفحه از وب‌سایتیک صفحه ممکن است با آدرس‌های متفاوتی در وبسایت شما نمایش داده شود. مانند شخصی که نامش در شناسنامه یک چیز است و در خانه طور دیگری صدایش می‌کنند. ماهیت آدرس کنونیکال (Canonical URL) در واقع این است که به موتورهای جستجو بگوید کدام URL نام سجلی صفحه است. اگر گذارتان به سایتی مثل استک‌اورفلو افتاده باشد و به آدرس صفحه دقت کرده باشید چیزی شبیه این عایدتان میشود: stackoverflow.com/questions/79358785/how-can-i-ensure-two-grid-columns-are-equal-in-width-when-the-first-columns-con قسمت آخر URL را که نگاه کنید قسمتی را می‌بینید که شما احتمالا به از من می‌دانید چیست. اسلاگ (Slug) بخش توصیفی و خوانای یک URL است که به‌صورت مختصر، محتوای صفحه را معرفی می‌کند (و اغلب قریب به اتفاق عنوان اصلی صفحه است که با کمی تغییر در آدرس قرار می‌گیرد). این قسمت از آدرس هم به آدم‌ها کمک میکند تا بدون دیدن صفحه بتوانند حدس بزنند که چه چیزی در آن صفحه انتظارشان را می‌کشد، هم به موتورهای جستجو در ایندکس کردن صفحه کمک می‌کند(و باعث بهبود سئوی صفحه در موتورهای جستجو می‌شود). با این اوضاف اگر در آدرس قبلی این قسمت انتهایی را حذف کنید می‌شود این آدرس:stackoverflow.com/questions/79358785 روی لینک که کلیک کنید به همان صفحه قبلی منتقل می‌شوید با کد ۳۰۱ ریدایرکت (301 redirect). به کجا؟ به آدرس کنونیکال.301 redirect - Moved Permanently تا اینجا این روزی روزگاریها را به هم بافتم که برسم به مقصود اصلی این نوشتار.دوم: هویت آن است که با وجود تغییراتی که در اوقات مختلف عارض وجود گردند، وحدت ذات داشته باشد.مدیریت آدرس‌ها با ریسپانس ۳۰۱ برای حفظ هویت صفحه اسلاگ‌ها با وجودی که برای صفحه شما پیشِ موتورهای جستجو اعتبار می‌خرند اگر در صورت تغییر درست مدیریت نشوند شبیه چک بلامحلی میشوند که اعتبار سایت شما را زیر سوال می‌برند و به قولی گوگل برایتان پنالتی در نظر می‌گیرد. اگر باز کمی دقت کنیم هربار که عنوان سوال در استک‌اورفلو تغییر می‌کند اسلاگ عوض می‌شود. اما شما اگر همان آدرس قبلی را بزنید با کد ریسپانس ۳۰۱ آدرس جدید منتقل می‌شوید و اینطوری هم کاربر متوجه تغییر نمیشود و هم به موتور جستجو میگوییم این صفحه همان صفحه قبلیاست. هویت با وجود تغییرات همان است که بود. پس بهتر آن است که همیشه فرض بگیریم آدرسها ممکن است تغییر کنند.گرچه این ماجرا ساده‌است؛ اما به قول معروف شیطان همیشه در جزئیات است. جزئیاتی که همیشه پشت گوش می‌اندازیم تا شاید روزی سراغشان برویم و سر آخر هم مدیریت نکردن همین چیزهای کوچک و ساده ممکن است فاصله‌های زیاد را ایجاد کنند و معنا شوند.کلید ساده ماجرا این است که شما همیشه صفحه را با آیدی جستجو کنید و اگر اسلاگ آنی نبود که توی دیتابیس شما ذخیره شده در جواب آدرس کنونیکال را با کد ۳۰۱ برگردانید. همین!اگر کد شما از تمپلیت استفاده میکند همه چیز به سادگی میتواند اتفاق بیافتد:Route::get('/posts/{id}/{slug?}', function ($id, $slug = null) { $post = Post::findOrFail($id); if ($slug !== $post->slug) { return redirect()->to('/posts/' . $post->id . '/' . $post->slug, 301); } return view('post.show', compact('post')); });اگر هم دارید restAPI کار می‌کنید تغییر کوچک زیر همه چیز را حل می‌کند:Route::get('/api/posts/{id}/{slug?}', function ($id, $slug = null) { $post = Post::findOrFail($id); if ($slug !== $post->slug) { return response()->json([ 'redirect_url' => url(&quot/posts/{$post->id}/{$post->slug}&quot) ], 301); } return response()->json($post); });سمت کلاینت هم اگر در فرانت‌اند سرور رندرینگ (SSR) مانند Next.js استفاده شود کافی‌است ریسپانس را سمت سرور چک کنید و اگر لازم بود ریدایرکت را با هدر لوکیشن انجام دهید:if (response.status === 301) { const data = await response.json(); .href = data.redirect_url; }موتورهای جستجو در صورت مشاهده‌ی این هدر و کد ۳۰۱ متوجه تغییر دائمی آدرس می‌شوند و اعتبار صفحه قبلی را به صفحه جدید منتقل می‌کنند. بدون این هدر، موتورهای جستجو ممکن است تغییر مسیر را شناسایی نکنند و محتوای صفحه را به عنوان محتوای تکراری (Duplicate Content) در نظر بگیرند.در واقع هدر لوکیشن بخشی از استاندارد پروتکل HTTP است و برای ریدایرکتهای 3xx استفاده میشود. این هدر به همراه کد 3xx ارسال میشود و مرورگر را موظف میکند کاربر را به URL جدید ببرد. Karim Pazoki Karim Pazoki Sat, 18 Jan 2025 13:41:34 +0330 https://virgool.io/@kaafochino/%D9%85%D8%AE%D8%AA%D8%B5%D8%B1%DB%8C-%D8%AF%D8%B1-%D8%A8%D8%A7%D8%A8-%D8%AA%D8%B2%D8%B1%DB%8C%D9%82-%D9%88%D8%A7%D8%A8%D8%B3%D8%AA%DA%AF%DB%8C-dependency-injection-%DA%AF%D9%81%D8%AA%D8%A7%D8%B1-%D8%A7%D9%88%D9%84-%DA%86%DB%8C%D8%B3%D8%AA%DB%8C-swtxv3ryycdc مقدمهاین پست بخش اول از یه مطلب نسبتا بلندتر در مورد تزریق وابستگی یا همون dependency injection خودمونه(نمیدونم کی خودمونی شدیم باهاش ولی به هر روی). برای اینکه پست زیادی طولانی نشه و خوندنش خارج از حوصله نباشه و همین‌طور زمان لازم برای نوشتن رو تقسیم و مدیریت کنم تصمیم گرفتم این مطلب رو به چندتا پست کوچیک‌تر تبدیل کنم تا بیشتر جای مانور داشته باشم. تو بخش اول این مطلب مختصرا میگم اصلا تزریق وابستگی چی هست. تو پستای بعدی راجع به این خواهم نوشت که چرا و چه زمانی از تزریق وابستگی استفاده می‌کنیم. راجع به مفهومی به نام کانتینر(‌‌container) خواهم نوشت. تو بخشای بعدی چندتا مثال همراه با کد هم برای درک بهتر تو پیاده‌سازی می‌ذارم.با این مقدمه میرم سر اصل مطلب!اول ببینیم تزریق وابستگی (dependency injection) چیه؟خب بیاین ببینیم اصلا وابستگی یعنی چی؟! وقتی کلاس A نیاز داشته باشه از یک سری از متدای کلاس B استفاده کنه می‌گیم کلاس A به کلاس ‌B وابسته‌س. بنابراین قبل از این که بتونیم از متدای یه کلاس استفاده کنیم باید یه نمونه از اون کلاس ایجاد کنیم. مثلا اینجا کلاس A میتونه یه نمونه از کلاس B بسازه و داستان رو پیش ببره. حالا اگه کار ساختن نمونه از B رو یکی دیگه بعهده بگیره و نمونه ساخته شده رو پاس بده به ‌A تا A بتونه ازش استفاده کنه بهش می‌گیم تزریق وابستگی. به زبون ساده‌تر!به جای اینکه اجازه بدی کلاس ‌A یه نمونه از ‌کلاس ‌‌B رو داخل خودش بسازه خودت یه نمونه از کلاس ‌B رو بساز و پاس بده بهش.توضیحات بالا رو یه قیاس بکنم با دنیای واقعی؛ مثلا تولید کننده ماشین برای ساخت ماشیناش نیاز داره به باتری و تایر و امثالهم. حالا تولید کننده ماشین میتونه کار ساخت باتری و تایر و این داستان‌ها رو بسپره به یه کارخونه‌ی دیگه و اون کارخونه‌ی ثانی باتری رو بسازه و بده به کارخونه اول. اینجوری دیگه کارخونه ماشین نیازی نداره باتری‌ها رو خودش بسازه.مثال زیر نشون میده اگه بدون تزریق وابستگی پیش بریم باید چیکار کنیم: - اپلیکیشن به کلاس A نیاز داره.- اپلیکیشن یه نمونه از کلاس A می‌سازه.- اپلیکیشن کلاس ‌A رو فراخونی می‌کنه. .......+ کلاس ‌A به کلاس ‌‌B نیاز داره. .......+ کلاس A یه نمونه از کلاس B می‌سازه. .......+ کلاس A کلاس B رو فراخونی می‌کنه. ....... .......* کلاس ‌B به کلاس C نیاز داره. ....... .......* کلاس B یه نمونه از کلاس C می‌سازه. ....... .......* کلاس B کاری که باید رو انجام میده.حالا همین کار رو یه بار دیگه با تزریق وابستگی اگر انجام بدیم فرایند به این شکل میشه:- اپلیکیشن به کلاس A نیاز داره که A خودش به ‌B نیاز داره که اونم خودش به C نیاز داره.- اپلیکیشن یه نمونه از C ایجاد میکنه.- اپلیکیشن یه نمونه از B ایجاد میکنه و C رو بهش پاس میده.- اپلیکیشن یه نمونه از A ایجاد میکنه و B رو بهش پاس میده.- اپلیکیشن کلاس ‌A رو فراخونی می‌کنه. .......+ کلاس A کلاس B رو فراخونی می‌کنه. ....... .......* کلاس B کاری که باید رو انجام میده.در حقیقت اینجا اومدیم و طبق تعریف کار ساخت کلاس ‌B و C رو گذاشتیم به عهده اپلیکیشن و نمونه ها رو پاس دادیم به کلاس‌هایی که بهشون نیاز د اشتن. اتفاقی که اینجا افتاده اینه که کنترل وابستگی رو از کلاسی که فراخونی میکنه (‌A) به کلاسی که فراخونی میشه (B) معکوس کردیم که به این پترن میگن وارونگی کنترل (Inversion of Control). با این روش کنترل نسبتا کاملی روی وابستگی‌ها خواهیم داشت و تو بخشای بعدی با مثال توضیح خواهم داد که کنترلمون روی اپلیکیش با این روش چه تغییری خواهد کرد.** پایان بخش اول ** Karim Pazoki Karim Pazoki Sun, 17 Jul 2022 17:20:58 +0430