اگر به‌تازگی Laravel را نصب کرده باشید، احتمالاً بعد از ایجاد اولین پروژه با تعداد زیادی پوشه و فایل مواجه شده‌اید و این سؤال برایتان پیش آمده است که:
هرکدام از این پوشه‌ها چه کاربردی دارند و کدهای پروژه را باید دقیقاً در کدام قسمت قرار دهیم؟
شناخت ساختار پروژه Laravel یکی از مهم‌ترین مباحثی است که هر توسعه‌دهنده Laravel باید یاد بگیرد. اگر ساختار پروژه را به‌درستی بشناسید، هنگام توسعه قابلیت‌های جدید، پیدا کردن فایل‌ها، رفع خطاها و مدیریت پروژه بسیار ساده‌تر خواهد شد.
در این مقاله ساختار یک پروژه Laravel را از بالا به پایین بررسی می‌کنیم و توضیح می‌دهیم هر پوشه و فایل چه وظیفه‌ای دارد، چه زمانی باید آن را تغییر دهید و چه بخش‌هایی معمولاً نباید مستقیماً دستکاری شوند.
ساختار پروژه Laravel چیست؟
وقتی یک پروژه Laravel ایجاد می‌کنید، فریم‌ورک مجموعه‌ای از پوشه‌ها و فایل‌های استاندارد را در اختیار شما قرار می‌دهد.
یک ساختار کلی پروژه Laravel معمولاً چیزی شبیه نمونه زیر است:
laravel-project/
│
├── app/
├── bootstrap/
├── config/
├── database/
├── public/
├── resources/
├── routes/
├── storage/
├── tests/
├── vendor/
│
├── .env
├── .env.example
├── artisan
├── composer.json
├── composer.lock
├── package.json
├── phpunit.xml
├── vite.config.js
└── ...
البته بسته به نسخه Laravel، پکیج‌های نصب‌شده و تنظیمات پروژه ممکن است فایل‌ها و پوشه‌های دیگری نیز وجود داشته باشند.
نکته مهم این است که هر بخش از این ساختار مسئولیت مشخصی دارد و قرار نیست تمام کدهای پروژه را در یک پوشه قرار دهید.
# چرا شناخت ساختار پروژه Laravel مهم است؟
فرض کنید می‌خواهید یک صفحه جدید ایجاد کنید.
آیا باید فایل آن را داخل app قرار دهید؟
یا resources؟
یا public؟
اگر بخواهید یک Route جدید ایجاد کنید چه؟
اگر بخواهید تنظیمات دیتابیس را تغییر دهید چه؟
اگر بخواهید یک Migration بسازید چطور؟
Laravel برای هرکدام از این وظایف محل مشخصی دارد.
شناخت ساختار پروژه باعث می‌شود:
- پروژه منظم باقی بماند.
- پیدا کردن فایل‌ها ساده‌تر شود.
- توسعه قابلیت‌های جدید سریع‌تر انجام شود.
- اعضای تیم راحت‌تر روی پروژه کار کنند.
- نگهداری پروژه ساده‌تر شود.
- احتمال قرار دادن اشتباه فایل‌ها کاهش پیدا کند.
- معماری استاندارد Laravel بهتر رعایت شود.
# پوشه‌های اصلی پروژه Laravel
حالا مهم‌ترین پوشه‌های پروژه را بررسی کنیم.
پوشه app
یکی از مهم‌ترین قسمت‌های پروژه Laravel، پوشه app است.
کد اصلی برنامه معمولاً در این قسمت قرار می‌گیرد.
درون app نیز پوشه‌های مختلفی وجود دارد که هرکدام مسئول بخش مشخصی از منطق برنامه هستند.
برای مثال:
app/
├── Console/
├── Exceptions/
├── Http/
├── Models/
└── Providers/
البته بسته به نسخه Laravel و ساختار پروژه، ممکن است زیرپوشه‌های دیگری نیز وجود داشته باشند.
پوشه app/Http
بخش مهمی از منطق مربوط به HTTP در این قسمت قرار می‌گیرد.
برای مثال در پروژه‌های Laravel ممکن است مواردی مانند موارد زیر را در این بخش مشاهده کنید:
app/Http/
├── Controllers/
├── Middleware/
└── Requests/
Controllers
کنترلرها معمولاً در این مسیر قرار می‌گیرند:
app/Http/Controllers/
برای مثال:
app/Http/Controllers/ProductController.php
کنترلر می‌تواند مسئول دریافت درخواست و هماهنگ کردن بخش‌های مختلف برنامه باشد.
مثلاً:
public function show()
{
return view('products.show');
}
بعداً در مقاله اختصاصی Controller در Laravel به‌صورت کامل‌تر با این بخش کار خواهیم کرد.
Middleware
Middlewareها نیز معمولاً در این ساختار قرار می‌گیرند:
app/Http/Middleware/
Middleware می‌تواند درخواست HTTP را قبل از رسیدن به مقصد بررسی یا پردازش کند.
برای مثال می‌توان از Middleware برای بررسی دسترسی کاربر استفاده کرد.
موضوع Middleware در ادامه این Cluster به‌صورت جداگانه بررسی خواهد شد.
Form Request
در پروژه‌هایی که Validation را از Controller جدا می‌کنیم، می‌توانیم از Form Request استفاده کنیم.
فایل‌های مربوط به آن معمولاً در:
app/Http/Requests/
قرار می‌گیرند.
مثلاً:
app/Http/Requests/StoreProductRequest.php
این کار باعث می‌شود Controllerها بیش از حد شلوغ نشوند و منطق اعتبارسنجی ساختار مرتب‌تری داشته باشد.
# پوشه app/Models
مدل‌های Eloquent معمولاً در این قسمت قرار می‌گیرند:
app/Models/
مثلاً:
app/Models/User.php
app/Models/Product.php
app/Models/Order.php
یک مدل می‌تواند نماینده یک موجودیت در سیستم باشد.
برای مثال:
class Product extends Model
{
//
}
اگر پروژه شما فروشگاهی باشد، ممکن است مدل‌هایی مانند:
Product
Order
Customer
Category
Payment
داشته باشید.
مدل‌ها در Laravel با Eloquent ORM ارتباط بسیار نزدیکی دارند که در مقالات بعدی به‌صورت تخصصی بررسی خواهد شد.
# پوشه app/Providers
Service Providerها در Laravel برای ثبت و پیکربندی بخش‌های مختلف برنامه استفاده می‌شوند.
مسیر این بخش:
app/Providers/
است.
برای مثال ممکن است Providerهای مربوط به سرویس‌های مختلف پروژه در این قسمت قرار بگیرند.
اگر در پروژه‌ای نیاز داشته باشید یک سرویس یا قابلیت خاص را در چرخه راه‌اندازی برنامه ثبت کنید، Service Provider می‌تواند نقش مهمی داشته باشد.
# پوشه bootstrap
پوشه bootstrap مربوط به راه‌اندازی اولیه فریم‌ورک است.
در این قسمت فایل‌هایی قرار دارند که برای Bootstrap شدن برنامه مورد استفاده قرار می‌گیرند.
در پروژه‌های Laravel نباید این پوشه را محلی برای قرار دادن منطق اصلی برنامه در نظر بگیرید.
به زبان ساده:
app
محل اصلی کدهای برنامه است، در حالی که:
bootstrap
بخش‌هایی از فرآیند آماده‌سازی و راه‌اندازی فریم‌ورک را مدیریت می‌کند.
# پوشه config
تنظیمات مختلف برنامه در پوشه:
config/
قرار می‌گیرند.
برای مثال ممکن است فایل‌هایی مانند موارد زیر را مشاهده کنید:
config/
├── app.php
├── auth.php
├── cache.php
├── database.php
├── filesystems.php
├── logging.php
├── mail.php
├── queue.php
└── services.php
این فایل‌ها تنظیمات بخش‌های مختلف Laravel را در خود نگه می‌دارند.
تنظیمات دیتابیس
برای تنظیمات دیتابیس معمولاً فایل زیر اهمیت دارد:
config/database.php
اما اطلاعات محیطی مانند مشخصات اتصال دیتابیس معمولاً از .env خوانده می‌شوند.
برای مثال:
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=my_database
DB_USERNAME=root
DB_PASSWORD=
بنابراین نباید اطلاعات حساس را مستقیماً در فایل‌های عمومی پروژه قرار دهید.
# پوشه database
همان‌طور که از نام آن مشخص است، پوشه database با بخش دیتابیس پروژه ارتباط دارد.
در این قسمت معمولاً مواردی مانند:
database/
├── factories/
├── migrations/
└── seeders/
قرار می‌گیرند.
Migrations
Migrationها برای تعریف و تغییر ساختار دیتابیس استفاده می‌شوند.
برای مثال:
database/migrations/
ممکن است شامل فایلی برای ایجاد جدول محصولات باشد.
نمونه:
Schema::create('products', function (Blueprint $table) {
$table->id();
$table->string('name');
$table->decimal('price', 12, 2);
$table->timestamps();
});
به این ترتیب ساختار دیتابیس نیز همراه پروژه قابل مدیریت و انتقال خواهد بود.
Seeders
Seederها برای وارد کردن داده‌های اولیه یا نمونه به دیتابیس استفاده می‌شوند.
مسیر:
database/seeders/
است.
برای مثال می‌توان یک Seeder برای ایجاد نقش‌های اولیه یا چند کاربر آزمایشی ایجاد کرد.
Factories
Factoryها برای تولید داده‌های آزمایشی و ساخت رکوردهای نمونه بسیار کاربردی هستند.
مسیر:
database/factories/
است.
این قابلیت مخصوصاً هنگام تست و توسعه پروژه‌هایی که به تعداد زیادی داده آزمایشی نیاز دارند، مفید است.
# پوشه public
پوشه public یکی از مهم‌ترین بخش‌های پروژه از نظر دسترسی وب‌سرور است.
در یک Laravel استاندارد، وب‌سرور باید به شکلی تنظیم شود که Document Root پروژه روی پوشه public قرار بگیرد.
ساختار ساده:
public/
├── index.php
├── favicon.ico
└── ...
فایل:
public/index.php
نقطه ورود اصلی درخواست‌های وب به برنامه Laravel است.
به همین دلیل نباید کل ریشه پروژه Laravel را مستقیماً به‌عنوان Document Root وب‌سرور قرار دهید.
# چرا فقط public باید در معرض وب باشد؟
فرض کنید پروژه شما در این مسیر قرار دارد:
/home/example/my-laravel-app/
بهتر است وب‌سرور به:
/home/example/my-laravel-app/public
اشاره کند.
چون فایل‌هایی مانند:
.env
composer.json
نباید مستقیماً از طریق وب قابل دسترسی باشند.
این موضوع یکی از نکات مهم امنیتی هنگام Deploy کردن Laravel است.
# پوشه resources
فایل‌های مربوط به منابع قابل پردازش پروژه معمولاً در:
resources/
قرار می‌گیرند.
یکی از مهم‌ترین بخش‌های آن:
resources/views/
است.
Viewهای Blade معمولاً در این قسمت قرار می‌گیرند.
مثلاً:
resources/views/
├── home.blade.php
├── products/
│ ├── index.blade.php
│ └── show.blade.php
└── layouts/
└── app.blade.php
برای مثال:
return view('products.index');
می‌تواند View مربوط به:
resources/views/products/index.blade.php
را نمایش دهد.
# فایل‌های Front-End در resources
علاوه بر Viewها، فایل‌های مربوط به منابع Front-End پروژه نیز می‌توانند در resources قرار بگیرند.
برای مثال:
resources/
├── css/
└── js/
در پروژه‌هایی که از Vite استفاده می‌کنند، این فایل‌ها در فرآیند Build مربوط به Front-End وارد می‌شوند.
بنابراین باید بین:
resources
و:
public
تفاوت قائل شوید.
resources بیشتر محل منابعی است که قرار است پردازش یا Build شوند، در حالی که public محل فایل‌هایی است که مستقیماً برای دسترسی وب ارائه می‌شوند.
# پوشه routes
Routeهای برنامه Laravel در پوشه:
routes/
قرار می‌گیرند.
این پوشه یکی از مهم‌ترین قسمت‌های پروژه برای تعریف مسیرهای برنامه است.
بسته به ساختار پروژه ممکن است فایل‌هایی مانند:
routes/
├── web.php
├── api.php
├── console.php
└── channels.php
وجود داشته باشند.
فایل web.php
Routeهای مربوط به رابط وب معمولاً در:
routes/web.php
قرار می‌گیرند.
مثلاً:
Route::get('/about', function () {
return view('about');
});
وقتی کاربر آدرس:
/about
را باز می‌کند، Laravel این Route را بررسی می‌کند.
فایل api.php
در پروژه‌هایی که Routeهای API در این فایل تعریف شده باشند، مسیر:
routes/api.php
برای Routeهای API استفاده می‌شود.
مثلاً:
Route::get('/products', function () {
return Product::all();
});
در پروژه‌های API محور، این بخش اهمیت زیادی پیدا می‌کند.
فایل console.php
Routeهای مربوط به قابلیت‌های Console و برخی تعریف‌های مربوط به دستورات کنسولی می‌توانند در:
routes/console.php
قرار بگیرند.
این بخش را نباید با routes/web.php اشتباه گرفت.
# پوشه storage
Laravel برای ذخیره برخی فایل‌ها، لاگ‌ها و داده‌های تولیدشده توسط برنامه از:
storage/
استفاده می‌کند.
ساختار آن می‌تواند شامل بخش‌هایی مانند:
storage/
├── app/
├── framework/
└── logs/
باشد.
storage/app
برای فایل‌هایی که برنامه ذخیره می‌کند، storage/app اهمیت زیادی دارد.
برای مثال ممکن است فایل‌های آپلودشده کاربران در این بخش ذخیره شوند.
storage/logs
فایل‌های Log برنامه معمولاً در:
storage/logs/
قرار می‌گیرند.
اگر برنامه با خطایی مواجه شود، بررسی Logها یکی از اولین کارهایی است که یک توسعه‌دهنده Laravel انجام می‌دهد.
storage/framework
Laravel برای برخی فایل‌های موقت و داده‌های مورد استفاده Framework از این بخش استفاده می‌کند.
در نتیجه نباید بدون دلیل فایل‌های این قسمت را حذف یا تغییر دهید.
# پوشه tests
تست‌های پروژه در:
tests/
قرار می‌گیرند.
معمولاً تست‌ها به دو گروه اصلی تقسیم می‌شوند:
tests/
├── Feature/
└── Unit/
Feature Test
برای آزمایش رفتار یک قابلیت یا بخش نسبتاً کامل از برنامه استفاده می‌شود.
Unit Test
برای آزمایش واحدهای کوچک‌تر برنامه استفاده می‌شود.
تست‌نویسی در ادامه Cluster Laravel به‌صورت جداگانه بررسی خواهد شد.
# پوشه vendor
اگر با Composer کار کرده باشید، احتمالاً پوشه:
vendor/
را دیده‌اید.
این پوشه شامل وابستگی‌های PHP پروژه است که توسط Composer نصب شده‌اند.
مثلاً وقتی دستور:
composer install
را اجرا می‌کنید، Composer وابستگی‌های تعریف‌شده پروژه را دریافت و نصب می‌کند.
آیا باید vendor را دستی ویرایش کنیم؟
خیر.
به‌صورت معمول نباید فایل‌های داخل vendor را مستقیماً ویرایش کنید.
اگر پکیجی نیاز به تغییر دارد، باید روش مناسبی برای آن در نظر بگیرید؛ چون تغییر مستقیم vendor ممکن است با نصب یا به‌روزرسانی بعدی از بین برود.
# فایل .env
یکی از مهم‌ترین فایل‌های پروژه:
.env
است.
این فایل معمولاً برای نگهداری تنظیمات محیط اجرای پروژه استفاده می‌شود.
برای مثال:
APP_NAME=Laravel
APP_ENV=local
APP_KEY=
APP_DEBUG=true
APP_URL=http://localhost
و همچنین تنظیمات دیتابیس:
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=laravel
DB_USERNAME=root
DB_PASSWORD=
می‌توانند در آن قرار بگیرند.
آیا .env را باید در Git قرار دهیم؟
معمولاً نباید فایل .env حاوی اطلاعات حساس پروژه را در Repository عمومی قرار دهید.
این فایل ممکن است شامل مواردی مانند:
- رمز دیتابیس
- کلیدهای API
- اطلاعات سرویس‌های خارجی
- اطلاعات Mail
- Secretها
باشد.
به همین دلیل باید در مدیریت آن دقت زیادی داشته باشید.
# فایل .env.example
در کنار .env معمولاً فایل:
.env.example
وجود دارد.
این فایل نمونه‌ای از متغیرهای محیطی مورد نیاز پروژه را نشان می‌دهد.
تفاوت مهم:
.env
تنظیمات واقعی محیط شما را نگه می‌دارد.
اما:
.env.example
بیشتر برای مشخص کردن متغیرهایی است که یک محیط جدید برای اجرای پروژه به آن‌ها نیاز دارد.
# فایل artisan
یکی از فایل‌های مهم Laravel:
artisan
است.
این فایل ابزار Command Line Interface مربوط به Laravel را در اختیار شما قرار می‌دهد.
برای مثال:
php artisan serve
برای اجرای سرور توسعه استفاده می‌شود.
یا:
php artisan make:controller ProductController
برای ایجاد Controller.
در واقع Artisan یکی از ابزارهای اصلی شما برای کار با پروژه Laravel است.
مقاله بعدی این Cluster دقیقاً به Artisan اختصاص دارد.
# فایل composer.json
فایل:
composer.json
یکی از مهم‌ترین فایل‌های پروژه PHP و Laravel است.
در این فایل اطلاعاتی مانند:
- وابستگی‌های PHP
- نسخه‌های مورد نیاز
- Scriptها
- تنظیمات Autoload
- اطلاعات مربوط به پکیج‌های پروژه
تعریف می‌شوند.
برای مثال ممکن است در آن وابستگی‌های Laravel و سایر Packageهای پروژه تعریف شده باشند.
# فایل composer.lock
فایل:
composer.lock
نسخه دقیق Dependencyهایی را که برای پروژه انتخاب شده‌اند، ثبت می‌کند.
وجود این فایل کمک می‌کند محیط‌های مختلف پروژه از نسخه‌های یکسان یا مورد انتظار Dependencyها استفاده کنند.
به همین دلیل در پروژه‌های معمولاً قابل استقرار، مدیریت درست composer.lock اهمیت زیادی دارد.
# فایل package.json
اگر پروژه Laravel از ابزارهای Front-End و Node.js استفاده کند، فایل:
package.json
برای تعریف Packageهای JavaScript و Scriptهای مربوط به پروژه استفاده می‌شود.
برای مثال ممکن است ابزارهایی مانند Vite در Dependencyهای پروژه تعریف شوند.
# فایل vite.config.js
در پروژه‌هایی که از Vite استفاده می‌کنند، فایل تنظیمات Vite نیز در ریشه پروژه قرار می‌گیرد.
مثلاً:
vite.config.js
این فایل برای تنظیم فرآیند Build و پردازش منابع Front-End پروژه کاربرد دارد.
# فایل phpunit.xml
این فایل مربوط به تنظیمات تست پروژه است.
مثلاً:
phpunit.xml
می‌تواند تنظیمات مربوط به اجرای تست‌ها را مشخص کند.
اگر در آینده وارد بخش تست‌نویسی Laravel شوید، این فایل اهمیت بیشتری پیدا می‌کند.
# تفاوت public، resources و storage
این سه پوشه برای بسیاری از افراد تازه‌کار گیج‌کننده هستند.
| پوشه | کاربرد کلی |
|---|---|
public | فایل‌ها و نقطه ورود قابل ارائه توسط Web Server |
resources | منابع View و Front-End که می‌توانند پردازش شوند |
storage | فایل‌های تولیدشده، Uploadها، Cacheهای مربوط به Framework و Logها |
مثلاً اگر یک فایل CSS خام داشته باشید ممکن است در:
resources/css/
قرار بگیرد.
اما خروجی قابل ارائه وب می‌تواند در مسیر مناسب Build شود.
از طرف دیگر Log برنامه در:
storage/logs/
قرار می‌گیرد.
# مسیر کلی اجرای یک درخواست در Laravel
حالا که پوشه‌های اصلی را شناختیم، بهتر است ببینیم یک درخواست HTTP چه مسیری را طی می‌کند.
فرض کنید کاربر وارد:
/products
می‌شود.
به‌صورت ساده می‌توان فرآیند را این‌گونه تصور کرد:
Browser
↓
Web Server
↓
public/index.php
↓
Laravel Application
↓
Route
↓
Middleware
↓
Controller
↓
Model / Service / Database
↓
View یا Response
↓
Browser
این تصویر به شما کمک می‌کند بفهمید هر قسمت از ساختار پروژه چه جایگاهی دارد.
# هنگام توسعه هر قابلیت، کجا باید کد بنویسیم؟
یکی از کاربردی‌ترین سؤالات برای افراد تازه‌کار همین است.
فرض کنیم می‌خواهیم یک سیستم محصولات ایجاد کنیم.
ممکن است ساختار پروژه به این شکل شود:
app/
├── Http/
│ └── Controllers/
│ └── ProductController.php
│
└── Models/
└── Product.php
database/
└── migrations/
└── xxxx_xx_xx_create_products_table.php
resources/
└── views/
└── products/
├── index.blade.php
├── create.blade.php
└── show.blade.php
routes/
└── web.php
در اینجا هر بخش وظیفه مشخصی دارد.
Route
مسیر درخواست را مشخص می‌کند.
Route::get('/products', [ProductController::class, 'index']);
Controller
درخواست را مدیریت می‌کند.
public function index()
{
$products = Product::all();
return view('products.index', compact('products'));
}
Model
با داده‌ها و دیتابیس ارتباط برقرار می‌کند.
class Product extends Model
{
//
}
View
اطلاعات را به کاربر نمایش می‌دهد.
<h1>محصولات</h1>
@foreach ($products as $product)
<div>
{{ $product->name }}
</div>
@endforeach
این جداسازی باعث می‌شود پروژه ساختار قابل مدیریت‌تری داشته باشد.
# آیا باید تمام فایل‌های Laravel را تغییر دهیم؟
خیر.
یکی از اشتباهات رایج افراد تازه‌کار این است که تصور می‌کنند باید برای هر قابلیت، فایل‌های مختلف Framework را دستکاری کنند.
در اکثر مواقع شما با بخش‌هایی مانند:
app/
routes/
resources/
database/
config/
کار خواهید داشت.
در مقابل، نباید بدون دلیل فایل‌های داخلی:
vendor/
یا بخش‌های سیستمی Laravel را تغییر دهید.
# یک مثال عملی از ساختار پروژه فروشگاهی
فرض کنیم می‌خواهیم یک فروشگاه اینترنتی با Laravel ایجاد کنیم.
ساختار ساده پروژه می‌تواند چیزی شبیه این باشد:
app/
├── Http/
│ ├── Controllers/
│ │ ├── ProductController.php
│ │ ├── CartController.php
│ │ └── OrderController.php
│ │
│ └── Requests/
│ └── StoreProductRequest.php
│
└── Models/
├── Product.php
├── Category.php
├── Order.php
└── User.php
database/
├── factories/
├── migrations/
│ ├── create_products_table.php
│ ├── create_categories_table.php
│ └── create_orders_table.php
│
└── seeders/
resources/
└── views/
├── products/
├── cart/
└── orders/
routes/
└── web.php
storage/
└── logs/
public/
├── index.php
└── ...
این ساختار به مرور و با بزرگ‌تر شدن پروژه توسعه پیدا می‌کند.
# ساختار پروژه Laravel را حفظ کنید، اما بیش از حد هم وسواس نداشته باشید
یک نکته مهم این است که ساختار استاندارد Laravel به معنی این نیست که همه پروژه‌ها باید دقیقاً یک شکل داشته باشند.
یک پروژه ساده ممکن است فقط چند Controller و Model داشته باشد.
اما یک پروژه بزرگ می‌تواند شامل موارد بسیار بیشتری باشد:
Services
Actions
Repositories
DTOs
Policies
Jobs
Events
Listeners
Notifications
Rules
Resources
بنابراین ساختار پروژه با رشد سیستم تغییر می‌کند.
مهم این است که این تغییرات با یک معماری مشخص و قابل فهم انجام شوند.
# اشتباهات رایج در ساختار پروژه Laravel
۱. قرار دادن فایل‌های حساس در public
فایل‌هایی مانند .env نباید در معرض دسترسی عمومی قرار بگیرند.
۲. ویرایش مستقیم vendor
این کار معمولاً راهکار مناسبی نیست.
چون با نصب یا به‌روزرسانی Dependencyها ممکن است تغییرات شما از بین برود.
۳. قرار دادن همه منطق در Controller
مثلاً یک Controller با صدها خط کد که شامل:
- Validation
- Query
- Business Logic
- ارسال ایمیل
- پرداخت
- محاسبات
همگی در یک متد باشد.
در پروژه‌های بزرگ بهتر است منطق پیچیده به ساختارهای مناسب‌تری منتقل شود.
۴. قرار دادن Viewها در public
Viewهای Blade محلشان در:
resources/views/
است، نه public.
۵. اشتباه گرفتن storage با public
همه فایل‌هایی که برنامه تولید یا ذخیره می‌کند الزاماً نباید مستقیماً در public قرار بگیرند.
برای فایل‌های عمومی و قابل دسترسی باید ساختار ذخیره‌سازی مناسبی طراحی شود.
۶. قرار دادن اطلاعات حساس داخل Git
فایل .env می‌تواند شامل اطلاعات حساسی باشد.
بنابراین باید در Repository و مخصوصاً Repositoryهای عمومی مراقب آن باشید.
# برای شروع Laravel کدام پوشه‌ها را بیشتر بشناسیم؟
اگر تازه Laravel را شروع کرده‌اید، لازم نیست از روز اول تمام ساختار Framework را حفظ کنید.
ابتدا این موارد را به‌خوبی یاد بگیرید:
app/
routes/
resources/
database/
config/
public/
storage/
و فایل‌های:
.env
artisan
composer.json
را نیز بشناسید.
بعد از آن، با یادگیری موضوعات پیشرفته‌تر، قسمت‌های دیگر پروژه نیز برایتان کاملاً قابل درک خواهند شد.
# جمع‌بندی ساختار پروژه Laravel
ساختار Laravel به شکلی طراحی شده است که هر بخش وظیفه مشخصی داشته باشد.
مهم‌ترین قسمت‌ها را می‌توان این‌گونه خلاصه کرد:
| بخش | کاربرد |
|---|---|
app | کد اصلی برنامه |
app/Http | Controller، Middleware و Requestها |
app/Models | مدل‌های برنامه |
bootstrap | فرآیند راه‌اندازی اولیه Framework |
config | تنظیمات برنامه |
database | Migration، Seeder و Factory |
public | نقطه ورود وب و فایل‌های عمومی |
resources | Viewها و منابع Front-End |
routes | مسیرهای برنامه |
storage | Log، فایل‌ها و داده‌های تولیدشده |
tests | تست‌های پروژه |
vendor | Dependencyهای Composer |
.env | تنظیمات محیطی |
artisan | ابزار خط فرمان Laravel |
composer.json | Dependencyها و تنظیمات Composer |
package.json | Dependencyهای JavaScript |
اگر ساختار پروژه Laravel را به‌درستی درک کنید، در مقالات بعدی هنگام یادگیری Route، Controller، View، Blade، Middleware، Database و Eloquent دقیقاً می‌دانید هر بخش در کجای پروژه قرار می‌گیرد.
# سوالات متداول
ساختار پروژه Laravel چیست؟
ساختار پروژه Laravel مجموعه‌ای از پوشه‌ها و فایل‌های استاندارد است که هرکدام وظیفه مشخصی در اجرای برنامه، مدیریت کدها، تنظیمات، دیتابیس، Viewها، Routeها و فایل‌های پروژه دارند.
کد اصلی Laravel را در کدام پوشه بنویسیم؟
بخش قابل توجهی از کدهای اصلی برنامه در پوشه app قرار می‌گیرند. Controllerها، Modelها و بسیاری از اجزای منطق برنامه در زیرمجموعه‌های این پوشه قرار می‌گیرند.
Routeهای Laravel کجا قرار دارند؟
Routeها در پوشه routes قرار می‌گیرند و Routeهای وب معمولاً در routes/web.php تعریف می‌شوند.
Viewهای Laravel کجا هستند؟
Viewهای Blade معمولاً در مسیر:
resources/views/
قرار می‌گیرند.
فایل .env در Laravel چه کاربردی دارد؟
.env برای نگهداری تنظیمات محیط اجرای برنامه، مانند تنظیمات دیتابیس و برخی اطلاعات سرویس‌ها و Secretها، استفاده می‌شود.
آیا می‌توان پوشه vendor را تغییر داد؟
به‌صورت معمول نباید فایل‌های داخل vendor را مستقیماً ویرایش کنید؛ چون این فایل‌ها توسط Composer مدیریت می‌شوند.
پوشه public در Laravel چه کاربردی دارد؟
public نقطه ورود وب پروژه و محل فایل‌هایی است که باید توسط Web Server ارائه شوند. در Deploy استاندارد Laravel، Document Root وب‌سرور باید به این پوشه اشاره کند.
