| کانال توسعهدهندگان لاراول |
رفتن به کانال در Telegram
⭕️ کانال توسعهدهندگان لاراول دولوپیکس 💠 دولوپیکس | جامعه توسعهدهندگان ایرانی 💎 @Developix 🚀 Developix.ir 📌 پشتیبانی و تبلیغات: @DevelopixSupport
نمایش بیشتر1 540
مشترکین
+124 ساعت
+27 روز
-230 روز
آرشیو پست ها
خروجی این کد Laravel چیست؟
در نظر بگیرید روی یک پروژه Laravel دارید کار میکنید و از Collection برای دستکاری دادهها استفاده کردهاید. در کد زیر از ترکیب pluck، collapse و values استفاده شده است.
بهدقت به نوع دادهای که هر مرحله برمیگرداند توجه کنید و بگویید در انتها چه چیزی روی صفحه چاپ میشود.
سؤال:
خروجی نهایی اجرای این اسکریپت PHP چیست؟ (دقیقاً همان رشتهای که echo چاپ میکند را بنویسید)
🔖 #Laravel #PHP #لاراول
👤 Developix
💎 Channel: @DevelopixLaravel
با Migration Boost هاستایران، برای مهاجرت به سرور ابری دوباره هزینه ترافیک نده! 🚀
با خرید اولین سرور ابری غیرساعتی از **هاستایران**، بسته ترافیک هدیه مهاجرت بهصورت خودکار برای سرویس شما فعال میشود:
✅ حداقل ۱۰۰ گیگابایت ترافیک هدیه مهاجرت
✅ افزایش حجم هدیه متناسب با ظرفیت دیسک اولیه
✅ ترافیک آپلود رایگان
✅ بدون محدودیت زمانی
سرور ابری هاستایران را راهاندازی کنید و بکاپها، فایلها و پایگاه داده خود را بدون دغدغه هزینههای پنهان ترافیک منتقل کنید.
👇 مشاهده پلنهای سرور ابری هاستایران
hostiran.club/Migration
hostiran.club/Migration
Repost from N/a
🧩 ورژن 4 فریمورک LaraGram منتشر شد.
یکی از مهمترین قابلیتهای LaraGram 4، معرفی پکیج MTProto است؛ پکیجی که با هدف سادهسازی توسعه پروژههای مبتنی بر Telegram MTProto API طراحی شده است.
توسعه با MTProto معمولاً با چالشهایی مانند مدیریت Session، احراز هویت، نگهداری اتصال، دریافت Updateها، مدیریت Flood Wait و پیکربندیهای پیچیده همراه است. در LaraGram تلاش شده تمام این پیچیدگیها از مسیر توسعهدهنده حذف شود تا تجربهای مشابه توسعه یک ربات معمولی، اما با قدرت کامل MTProto داشته باشید.
⚡️ شروع کار بدون دردسر با LaraGram Installer
برای اینکه حتی مرحله راهاندازی هم ساده باشد، LaraGram Installer تمام مراحل اولیه را برای شما انجام میدهد.
با استفاده از Installer، فرآیندهایی مانند:
- نصب LaraGram
- نصب و آمادهسازی پکیج MTProto
- انجام کانفیگهای اولیه
- آمادهسازی ساختار پروژه
به صورت خودکار انجام میشود.
بعد از نصب، کافی است Handlerهای موردنظر خود را تعریف کنید و منطق برنامه را بنویسید؛ بخش زیادی از کارهای مربوط به زیرساخت، اتصال و مدیریت سرویس توسط خود LaraGram انجام خواهد شد.
⚡️ قدرت گرفته از Surge و Swoole/OpenSwoole
MTProto در LaraGram بر پایه Surge و Swoole/OpenSwoole توسعه داده شده است؛ یعنی به جای اجرای سنتی PHP، از یک Runtime دائمی و Event-Driven استفاده میکند.
این معماری باعث میشود MTProto بتواند برای ارتباطهای دائمی و پروژههای Real-Time عملکرد بسیار بهتری داشته باشد:
🚀 پردازش سریعتر Updateها
🔄 مدیریت همزمان اتصالها
💾 مصرف بهینهتر منابع
⚡️ حذف سربار اجرای مجدد برنامه
📈 آمادگی برای پروژههای بزرگ و پرترافیک
🧠 تمام امکانات MTProto، آماده استفاده
در MTProto LaraGram بسیاری از قابلیتهایی که معمولاً نیاز به پیادهسازی دستی دارند، به صورت داخلی فراهم شدهاند، به عنوان مثال شبیه سازی رفتار انسان، یا اعمال لیمیتهای خودکار به صورت هوشمند.
در نتیجه، توسعهدهنده به جای درگیر شدن با جزئیات سطح پایین، روی ساخت قابلیتهای اصلی پروژه تمرکز میکند.
نکته: به دلیل استفاده از Swoole/OpenSwoole، پکیج MTProto روی هاستهای اشتراکی قابل اجرا نیست و برای استفاده از آن به یک VPS نیاز خواهید داشت.🌐 MTProto + Web Routing؛ ساخت Telegram Client تحت وب یکی از جذابترین بخشهای LaraGram 4، ترکیب MTProto با Web Framework جدید LaraGram است. ترکیب این قابلیتها با MTProto به شما اجازه میدهد یک Telegram Web Client اختصاصی توسعه دهید؛ جایی که رابط کاربری از طریق سیستم وب LaraGram ساخته میشود و ارتباط مستقیم با تلگرام از طریق MTProto انجام میشود. یعنی با یک اکوسیستم واحد میتوانید: Backend وب را مدیریت کنید با Telegram API ارتباط داشته باشید حسابهای کاربری را مدیریت کنید کلاینتها و سرویسهای اختصاصی تلگرامی بسازید این تنها یکی از قابلیت های LaraGram است، پکیج Luna، یکی دیگر از آپدیتهای بزرگ LaraGram برای توسعه مینیاپ ها با React/Vue/Svelte بدون درگیری با API نویسی، SPAs، یا InitData تلگرام است. همچنین پکیجهایی برای توسعه با AI، ماینتورینگ ربات و... در حال توسعه هستند. نسخه 4 آغاز مسیر جدید LaraGram است؛ مسیری که این پروژه را از یک فریمورک ربات، به بستری کامل برای توسعه سرویسها، کلاینتها و اپلیکیشنهای مبتنی بر تلگرام تبدیل میکند. 📚 مستندات کامل: https://laraxgram.github.io ⭐️ اگر LaraGram برای شما مفید است، خوشحال میشویم با معرفی پروژه و دادن Star در GitHub از توسعه آن حمایت کنید: 🔹 گیتهاب LaraGram 🔹 گیتهاب MTProto 🔹 گیتهاب Luna
Repository Pattern در پروژههای لاراول 🧱
یکی از چیزهایی که پروژههای لاراول بزرگ را قابلنگهداریتر میکند، جدا کردن منطق دسترسی به دیتابیس از باقی لایههاست. اینجاست که Repository Pattern خیلی کمک میکند.
ایده ساده است: بهجای اینکه کنترلر مستقیم با
Model و کوئریها درگیر شود، با یک اینترفیس صحبت میکند. پشت این اینترفیس هر وقت خواستیم میتوانیم Eloquent را عوض کنیم، کش اضافه کنیم یا منبع داده را تغییر بدهیم، بدون اینکه کنترلر بشکند. 🔧
۱) تعریف Interface برای Repository
<?php
namespace App\Repositories;
interface UserRepositoryInterface
{
public function paginate(int $perPage = 15);
public function findById(int $id);
public function create(array $data);
}
۲) پیادهسازی با Eloquent
<?php
namespace App\Repositories;
use App\Models\User;
class EloquentUserRepository implements UserRepositoryInterface
{
public function paginate(int $perPage = 15)
{
return User::query()->latest()->paginate($perPage);
}
public function findById(int $id)
{
return User::query()->findOrFail($id);
}
public function create(array $data)
{
return User::query()->create($data);
}
}
۳) Bind کردن در Service Container لاراول
این کار را معمولاً در AppServiceProvider انجام میدهیم:
<?php
namespace App\Providers;
use Illuminate\Support\ServiceProvider;
use App\Repositories\UserRepositoryInterface;
use App\Repositories\EloquentUserRepository;
class AppServiceProvider extends ServiceProvider
{
public function register(): void
{
$this->app->bind(UserRepositoryInterface::class, EloquentUserRepository::class);
}
}
حالا هرجا UserRepositoryInterface را type-hint کنیم، بهطور خودکار EloquentUserRepository تزریق میشود. این همان قدرت Dependency Injection در لاراول است. ⚡️
۴) استفاده در Controller تمیزتر
<?php
namespace App\Http\Controllers;
use App\Repositories\UserRepositoryInterface;
use App\Http\Requests\StoreUserRequest;
class UserController extends Controller
{
public function __construct(
private readonly UserRepositoryInterface $users
) {}
public function index()
{
$users = $this->users->paginate(20);
return view('users.index', compact('users'));
}
public function store(StoreUserRequest $request)
{
$this->users->create($request->validated());
return redirect()->route('users.index');
}
}
حالا کنترلر فقط روی flow و پاسخ تمرکز دارد، نه روی جزئیات کوئریها. این کار:
• تستنویسی را سادهتر میکند (میتوان Mock از Repository ساخت) ✅
• وابستگی به Eloquent را از سطح کنترلر کم میکند ✅
• تغییرات دیتابیس یا اضافهکردن لایه cache را راحتتر میکند ✅
برای مطالعه عمیقتر، مستندات Service Container لاراول را ببینید:
https://laravel.com/docs/container
کمکم که پروژه بزرگتر میشود، استفاده درست از Repository Pattern میتواند ساختار کد را منظمتر، testableتر و قابلگسترشتر کند. از قدمهای کوچک شروع شود؛ مثلاً از ماژول User یا Order و بعد سایر بخشها را به این الگو مهاجرت بدهید. 🚀
🔖 #Laravel #PHP #لاراول #Laravel #Repository_Pattern #Clean_Code #Service_Container #PHP #Architecture
👤 Developix
💎 Channel: @DevelopixLaravel💠 نسخه جدید فریمورک لاراول (Laravel) منتشر شده است
🔸 ارتقا از نسخه 13.15.0 به 13.16.1
🔹 لیست تغییرات این نسخه:
- رفع مشکل ثبتنشدن برخی Dev Commandها
- بهبود پایدارسازی رجیستر شدن DevCommands
- سایر اصلاحات جزئی مرتبط با DevCommands و غیره
🔖 #laravel, #php, #laravel, #web, #release
💎 @DevelopixLaravel
💠 نسخه جدید فریمورک لاراول (Laravel) منتشر شده است
🔸 ارتقا از نسخه 13.14.0 به 13.15.0
💎 @DevelopixLaravel
پکیج امروز: spatie/laravel-permission برای مدیریت حرفهای نقشها و سطح دسترسی در Laravel 🔐
وقتی پروژه بزرگ میشود، ifهای تودرتو برای role و permission کد را بههم میریزد. این پکیج یک سیستم تمیز RBAC روی Eloquent میآورد و با Gate / Policy کاملاً سازگار است.
ویژگیها:
• تعریف role و permission داینامیک از دیتابیس 🧩
• attach شدن به User model با relationهای تمیز
• middleware آماده مثل
role و permission
• پشتیبانی از چند guard
نصب و استفاده سریع:
composer require spatie/laravel-permission
php artisan vendor:publish \
--provider\=
"Spatie\Permission\PermissionServiceProvider"
php artisan migrate
// در User model:
use Spatie\Permission\Traits\HasRoles;
class User extends Authenticatable
{
use HasRoles;
}
// استفاده:
$user->assignRole('admin');
$user->givePermissionTo('edit articles');
برای پنل ادمین، SaaS یا هر اپ multi-tenant، این پکیج واقعا زمان توسعه و باگهای دسترسی را کم میکند.
مستندات رسمی:
Docs
GitHub
امتحانش در پروژه بعدی، معماری auth شما را مرتبتر و قابلگسترشتر میکند 🚀
🔖 #Laravel #PHP #لاراول #Laravel #PHP #spatie #permission #RBAC #auth #eloquent
👤 Developix
💎 Channel: @DevelopixLaravelتمیز کردن کنترلرهای Laravel با Service Layer 🧼
خیلی وقتها کنترلرهای Laravel کمکم تبدیل میشوند به محل تجمع همهچیز: validation، منطق بیزنسی، queryهای Eloquent، ارسال notification و…
این یعنی:
• سختی در تست کردن 🧪
• کدهای تکراری در چند کنترلر
• سختی در تغییر منطق بیزنسی بدون شکستن endpointها
یکی از الگوهای ساده و کاربردی برای حل این مشکل در Laravel، استفاده از Service Layer است.
ایده اصلی ✨
هر action در کنترلر فقط کارهای زیر را انجام دهد:
• دریافت و validate ورودی
• صدا زدن یک Service (یا چند Service)
• برگرداندن Response مناسب (JSON / View)
تمام منطق بیزنسی داخل کلاسهای Service قرار میگیرد.
نمونه سناریو: ثبت سفارش 🛒
قبل از refactor (کنترلر چاق)
class OrderController extends Controller
{
public function store(Request $request)
{
$data = $request->validate([
'user_id' => ['required', 'exists:users,id'],
'items' => ['required', 'array'],
]);
$user = User::findOrFail($data['user_id']);
$order = DB::transaction(function () use ($user, $data) {
$order = $user->orders()->create();
foreach ($data['items'] as $item) {
$order->items()->create($item);
}
if ($user->isVip()) {
$order->applyDiscount(10);
}
return $order;
});
Notification::send($user, new OrderCreated($order));
return response()->json($order, 201);
}
}
کنترلر هم transaction دارد، هم business rule (Vip)، هم notification.
بعد از refactor با Service ✅
۱) ساخت Service:
namespace App\Services;
use App\Models\User;
use App\Notifications\OrderCreated;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Notification;
class OrderService
{
public function createOrderForUser(User $user, array $items)
{
$order = DB::transaction(function () use ($user, $items) {
$order = $user->orders()->create();
foreach ($items as $item) {
$order->items()->create($item);
}
if ($user->isVip()) {
$order->applyDiscount(10);
}
return $order;
});
Notification::send($user, new OrderCreated($order));
return $order;
}
}
۲) تزریق Service در کنترلر (Dependency Injection از Service Container):
use App\Models\User;
use App\Services\OrderService;
use Illuminate\Http\Request;
class OrderController extends Controller
{
public function __construct(private OrderService $orderService)
{
}
public function store(Request $request)
{
$data = $request->validate([
'user_id' => ['required', 'exists:users,id'],
'items' => ['required', 'array'],
]);
$user = User::findOrFail($data['user_id']);
$order = $this->orderService
->createOrderForUser($user, $data['items']);
return response()->json($order, 201);
}
}
مزایا 💡
• کنترلرها کوتاه و قابلخواندن
• قابلیت استفاده مجدد از منطق در Job، Command، Event Listener و…
• آمادهتر شدن برای تست واحد (Unit Test) روی Serviceها بهجای تستهای سنگین روی کنترلر
منابع پیشنهادی 📚
• مستندات Service Container در Laravel:
laravel.com/docs/container
این الگوی ساده اگر از همین امروز در پروژه لاراولتان اجرا شود، معماری تمیزتری میسازد و تغییرات بعدی را بسیار کمهزینهتر میکند 🌱
🔖 #Laravel #PHP #لاراول #Laravel #Service_Layer #Clean_Code #Controller #PHP #Architecture
👤 Developix
💎 Channel: @DevelopixLaravel⚡️ Eager Loading برای جلوگیری از N+1 در لاراول
خیلی وقتها کندی عجیب در صفحههایی دیده میشود که لیستها را با روابط Eloquent نمایش میدهند؛ ریشهاش معمولاً مشکل معروف N+1 Query است. خوشبختانه با یک تغییر کوچک در کوئری میشود کلی بهبود گرفت. 🚀
فرض کن هر
Post یک User دارد و موقع لیست پستها، نام نویسنده را هم نمایش میدهی. اگر ساده بنویسی:
$posts = Post::all();
foreach ($posts as $post) {
echo $post->user->name;
}
اینجا یک کوئری برای گرفتن همه پستها اجرا میشود و بعد برای هر پست یک کوئری جدا برای گرفتن user؛ یعنی N+1 کوئری 😬
بهجاش از eager loading استفاده کن:
$posts = Post::with('user')->get();
foreach ($posts as $post) {
echo $post->user->name;
}
حالا فقط دو کوئری اجرا میشود: یکی برای پستها، یکی برای همه کاربران مرتبط. هم تمیزتر، هم سریعتر، مخصوصاً روی دیتابیسهای سنگین. 🔥
مرجع: Laravel Docs - Eager Loading
این الگو را در همه لیستها و APIهای پرترافیک پروژه استفاده کن و تاثیرش را در لاگ و پروفایلینگ ببین. 😉
🔖 #Laravel #PHP #لاراول #Laravel #Eloquent #Performance #Eager_Loading #N+1
👤 Developix
💎 Channel: @DevelopixLaravelدر کد زیر داخل یک Controller تلاش شده روی مدل User فیلتر اعمال و نتیجه را paginate کند، اما از یک Anti Pattern جدی استفاده شده که میتواند باعث بروز باگ و رفتار غیرمنتظره شود:
use App\Models\User;
use Illuminate\Support\Facades\DB;
class UserController extends Controller
{
public function index()
{
$users = User::all();
$users = DB::table('users')
->where('is_active', true)
->paginate(15);
return view('users.index', compact('users'));
}
}
در این مثال ابتدا از Eloquent Model و بعد از آن مستقیماً از DB::table برای همان جدول استفاده شده است و همین موضوع باعث میشود مزایای Eloquent (مثل Accessor ها، Mutator ها، Scope ها و ...) دور زده شوند.
چه چیزی باید در این کد اصلاح شود تا فقط با استفاده از Eloquent مدل User، لیست کاربران فعال بهصورت صحیح paginate شود؟
🔖 #Laravel #PHP #لاراول
👤 Developix
💎 Channel: @DevelopixLaravel+1
در نمونهکد بالا، در حالت اول تمام رکوردها از دیتابیس خوانده میشوند و بعد با استفاده از Collection فیلتر میگردند که باعث افزایش شدید مصرف مموری و کاهش کارایی در جدولهای بزرگ میشود. در حالت دوم با تعریف یک Query Scope، منطق فیلتر مستقیماً روی کوئری SQL اعمال میشود و فقط دادههای لازم از دیتابیس لود میگردند.
شما در پروژههای Laravel خود به جای فیلتر کردن روی Collection بعد از
get() یا all()، میتوانید با استفاده از Local Scopeها منطق فیلتر را به لایه دیتابیس منتقل کنید؛ این کار علاوه بر خوانایی بهتر کد، باعث کاهش I/O دیتابیس، کاهش مصرف مموری و بهبود محسوس سرعت در کوئریهای سنگین میشود.
🔖 #Laravel #PHP #لاراول
👤 Developix
💎 Channel: @DevelopixLaravel+1
در نمونهکد بالا برای بدست آوردن تعداد کامنتهای هر پست از یک حلقه روی کالکشن استفاده شده که باعث بروز مشکل کلاسیک N+1 Query و افزایش شدید تعداد کوئریها در Laravel میشود. در نسخهی اصلاحشده با استفاده از متد
withCount() روی Eloquent Query Builder، تمام شمارشها در یک یا چند کوئری بهینه انجام شده و هم کارایی و هم زمان پاسخدهی در سناریوهایی با تعداد زیاد پست و کامنت بهطور محسوسی بهتر میشود.
🔖 #Laravel #PHP #لاراول
👤 Developix
💎 Channel: @DevelopixLaravelدر کد زیر میخواهیم لیست Categoryها را همراه با تعداد Postهای منتشرشده (status = 'published') بگیریم:
$categories = Category::query()
->withCount('posts')
->get();
foreach ($categories as $category) {
echo $category->name.": ".$category->posts
->where('status', 'published')
->count()."\n";
}
در این تکه کد هم از withCount استفاده شده و هم داخل حلقه روی رابطه posts فیلتر زده شده است که میتواند باعث N+1 Query و منطق اشتباه شود.
در مدل Category رابطه به این صورت تعریف شده است:
public function posts()
{
return $this->hasMany(Post::class);
}
چه چیزی باید در این کد اصلاح شود تا تعداد Postهای منتشرشده برای هر Category بهصورت بهینه و درست از دیتابیس گرفته شود؟
🔖 #Laravel #PHP #لاراول
👤 Developix
💎 Channel: @DevelopixLaravelRepost from ابر ویراک
ویراک کلود | تجربهی ابری بدون محدودیت ☁️🚀
🎁 ۲۰٪ شارژ هدیه روی اولین واریزی
مزیتهایی که واقعاً فرق میسازن:
⚡️ پهنای باند 980 مگ
🌐با IP مازاد
⏱️ راهاندازی فوری
💳 پرداخت ساعتی
🛡 پشتیبانی ۲۴/۷
💬 هر سوالی داشتی، تیم ما کنارتـه
✅ مناسب استارتاپها، تیمهای فنی، تا سازمانهای بزرگ
همین الان شروع کن و با حداکثر منابع، سریعتر رشد کن 👇🏻
📞 تماس سریع: 02191555530
🔗 https://virakcloud.com
ساخت Service Layer در لاراول برای تمیز نگهداشتن Controllerها 🧼
یکی از شایعترین مشکلات در پروژههای لاراول این است که Controllerها پر از منطق تجاری (Business Logic) میشوند؛ نتیجهاش کلاسهای چاق، سختقابلتست و بههمریخته است.
یک راهحل استاندارد و پرکاربرد، استفاده از Service Layer است؛ یعنی منطق اصلی را از Controller بیرون بکشیم و داخل Serviceهای مجزا قرار بدهیم. این رویکرد در پروژههای متوسط و بزرگ بهشدت روی مقیاسپذیری و تستپذیری تاثیر مثبت دارد. 💡
مثال ساده: ثبت کاربر با منطق داخل Controller (کد ناخوانا و شلوغ)
class RegisterController extends Controller
{
public function store(Request $request)
{
$data = $request->validate([
'name' => 'required',
'email' => 'required|email|unique:users,email',
'password' => 'required|min:8',
]);
$user = User::create([
'name' => $data['name'],
'email' => $data['email'],
'password' => Hash::make($data['password']),
]);
event(new Registered($user));
Mail::to($user->email)->send(new WelcomeMail($user));
return response()->json($user, 201);
}
}
همهچیز در یک متد جمع شده؛ اگر جای دیگری هم نیاز به همین منطق باشد، تکرار شروع میشود و تستنویسی سخت خواهد شد.
این منطق را به یک UserService منتقل میکنیم:
namespace App\Services;
use App\Models\User;
use App\Mail\WelcomeMail;
use Illuminate\Support\Facades\Hash;
use Illuminate\Support\Facades\Mail;
use Illuminate\Auth\Events\Registered;
class UserService
{
public function register(array $data): User
{
$user = User::create([
'name' => $data['name'],
'email' => $data['email'],
'password' => Hash::make($data['password']),
]);
event(new Registered($user));
Mail::to($user->email)->send(new WelcomeMail($user));
return $user;
}
}
حالا Controller فقط نقش هماهنگکننده دارد و بسیار تمیزتر است:
class RegisterController extends Controller
{
public function __construct(private UserService $userService) {}
public function store(RegisterRequest $request)
{
$user = $this->userService->register($request->validated());
return response()->json($user, 201);
}
}
نکات مهم ✅
• Dependency Injection از Service Container لاراول استفاده میکند؛ نیازی به new کردن دستی کلاسها نیست.
• با این ساختار، Unit Test برای UserService بدون نیاز به Request یا HTTP بسیار سادهتر میشود.
• Controllerها فقط ورودی/خروجی HTTP را مدیریت میکنند؛ منطق تجاری در Service قرار میگیرد و پروژه ساختار تمیزتر و قابلگسترشتری پیدا میکند.
برای مطالعه بیشتر، مستندات رسمی Service Container لاراول:
https://laravel.com/docs/container
قدمبهقدم هر منطق شلوغی را از Controller جدا و به Serviceها منتقل کنید؛ بعد از مدتی، معماری نرمافزار قابلحفاظتتر و توسعه ویژگیهای جدید لذتبخشتر میشود. 🚀
🔖 #Laravel #PHP #لاراول #Laravel #Service_Layer #Clean_Code #Architecture #PHP
👤 Developix
💎 Channel: @DevelopixLaravel+1
🔍 در مثال بالا در نسخهی اول برای گرفتن «پستهای محبوب کاربر» روی Eloquent Collection بعد از
get() فیلتر انجام شده و عملاً همهی رکوردها از دیتابیس خوانده میشوند. این کار روی جدولهای بزرگ میتواند باعث افزایش شدید مصرف مموری و زمان پاسخ شود. در نسخهی دوم با استفاده از Query Builder و انتقال شرط به خودِ کوئری، فیلتر روی سطح دیتابیس انجام میشود و فقط دادههای موردنیاز لود خواهند شد.
بهجای فیلتر کردن بعد از get() روی Collection، بهتر است تا حد امکان شرطها را قبل از اجرا شدن کوئری با متدهایی مثل where()، whereHas() و ... روی خود Query اعمال کنید تا هم مصرف مموری کم شود و هم سرعت پاسخدهی API در سناریوهای پرفشار بهتر شود.
🔖 #Laravel #PHP #لاراول
👤 Developix
💎 Channel: @DevelopixLaravel✳️ یک قطعه کد Eloquent در Laravel را در نظر بگیرید:
در این کد، ما در حال ساختن یک query روی مدل User هستیم و از local scopeها و یک macro روی Builder استفاده میکنیم:
<?php
use App\Models\User;
use Illuminate\Database\Eloquent\Builder;
Builder::macro('activeEmails', function () {
return $this->whereNotNull('email_verified_at')
->where('active', true)
->pluck('email')
->toArray();
});
// در مدل User فرض کنید این scope تعریف شده:
// public function scopeAdmin(Builder $query)
// {
// return $query->where('role', 'admin');
// }
$query = User::query();
$admins = $query->admin();
$all = $query->get();
$emails = $admins->activeEmails();
var_dump($all->count(), $admins->count(), $emails);
خروجی نهایی اجرای این اسکریپت (خروجی دقیق var_dump) چه خواهد بود؟
🔖 #Laravel #PHP #لاراول
👤 Developix
💎 Channel: @DevelopixLaravelدر کد زیر یک Anti Pattern خطرناک در Eloquent دیده میشود که میتواند باعث N+1 Query و مصرف زیاد منابع شود:
چه تغییری باید در این کد بدهید تا مشکل N+1 Query برطرف شود و کوئریها بهینه شوند؟
🔖 #Laravel #PHP #لاراول
👤 Developix
💎 Channel: @DevelopixLaravel
Repost from ابر ویراک
⭕️ ویراک کلود
زیرساختی مطمئن برای کسب و کارهای آنلاین
🎁 20% شارژ بیشتر روی اولین واریزی
⚡️با کد معرف: 10% شارژ برای شما و 10% برای دوستتان!
🔘با IPv6 رایگان
🔘با IP مازاد
🔘تست رایگان 2 روزه
🔘فایروال اختصاصی
🔘با API برای حرفهای ها
🔘پشتیبانی 24 ساعته
🔘آپلود رایگان
📞 همین حالا با ما تماس بگیرید و این فرصت فوقالعاده رو از دست ندید!
🔻02191555530
🌐Virakcloud.com
خیلی وقتها توی پروژههای Laravel بیدلیل همهٔ ستونهای جدول رو لود میکنیم، درحالیکه فقط ۲–۳ تا فیلد لازم داریم. همین کار ساده میتونه رم، زمان اجرا و حجم پاسخ API رو بیخودی سنگین کنه. 🚀
بهجای این:
$users = User::where('is_active', true)->get();
فقط همون فیلدهایی که لازم هست رو بگیر:
$users = User::where('is_active', true)
->select(['id', 'name', 'email'])
->get();
حالا اگه رابطه هم داری (مثلاً posts)، باز هم میشه کمحجم نگهش داشت:
$users = User::with(['posts:id,user_id,title'])
->select(['id', 'name'])
->get();
✅ نکتهها:
- ستون کلید خارجی (مثلاً user_id) حتماً توی select رابطه بیاد، وگرنه Eloquent نمیتونه رابطه رو درست مپ کنه.
- برای APIها و لیستهای بزرگ (لیست کاربران، محصولات، گزارشها) این کار واقعاً روی Performance تاثیر محسوس داره.
- موقع debug میشه موقتاً select رو برداشت تا مطمئن شد چیزی جا نمونده، بعد دوباره بهینهاش کرد. 😉
این عادت کوچیک که همیشه توی Queryها به select فکر کنی، جلوی کلی Memory Leak ریز و Query سنگین توی پروژههای بزرگ رو میگیره و API تمیزتر و سریعتری تحویل میده. 💡
برای جزئیات بیشتر مستند رسمی Laravel در مورد Eloquent & Query Builder:
https://laravel.com/docs/11.x/queries#select-statements
🔖 #Laravel #PHP #لاراول #Laravel #Eloquent #Performance #Query #select
👤 Developix
💎 Channel: @DevelopixLaravel