وقتی پروژه Laravel از چند صفحه Livewire، پنل ادمین، بلاگ و API تشکیل شده باشد، قرار دادن query و business logic داخل Controller یا Component خیلی زود بدهی فنی (Technical Debt) می‌سازد. راه‌حل استاندارد در پروژه‌های حرفه‌ای: Service Layer + Repository Pattern.
Service Layer چه کاری انجام می‌دهد؟
Service پاسخ «چه اتفاقی باید بیفتد» را می‌دهد — نه «چطور از دیتابیس بخوانیم». مثال‌های واقعی:
- ثبت مقاله بلاگ: slug یکتا، تنظیم
published_at، invalidate کش - تأیید دیدگاه: بررسی وضعیت، ارسال notification (در صورت نیاز)
- toggle فعال/غیرفعال: transaction + refresh cache
Controller یا Livewire فقط validate اولیه، فراخوانی Service و flash message را انجام می‌دهد.
Repository Pattern
Repository فقط مسئول ارتباط با persistence layer است. interface آن در Service inject می‌شود:
- تست unit سرویس بدون دیتابیس واقعی
- تمرکز queryهای پیچیده در یک کلاس
- جلوگیری از تکرار
where('is_active', true)در ده فایل مختلف
چک‌لیست Laravel 12
در پروژه فعلی portfolio از این موارد استفاده شده است:
- Enum برای وضعیت‌ها (
PostStatus,UserRole) - Constructor property promotion و type hint کامل
DB::transactionبرای عملیات چندمرحله‌ایloadMissing()برای جلوگیری از N+1 در صفحات بلاگ- Form validation در Livewire + ruleهای business در Service
اشتباه رایج
ساختن Service برای هر خط کد یا Repository با logic تجاری — هر دو anti-pattern هستند. Service باید orchestrator باشد؛ Repository فقط data access.
جمع‌بندی: اگر ۶ ماه بعد بخواهید فیچر جدید (مثلاً multi-vendor) اضافه کنید، لایه Service/Repository هزینه تغییر را به‌شدت کم می‌کند.
دیدگاه‌ها
هنوز دیدگاهی ثبت نشده است.
ثبت دیدگاه