Directory Structure

Introduction

The default Laravel application structure is intended to provide a great starting point for both large and small applications. But you are free to organize your application however you like. Laravel imposes almost no restrictions on where any given class is located - as long as Composer can autoload the class.

The Root Directory

The App Directory

The app directory contains the core code of your application. We'll explore this directory in more detail soon; however, almost all of the classes in your application will be in this directory.

The Bootstrap Directory

The bootstrap directory contains the app.php file which bootstraps the framework. This directory also houses a cache directory which contains framework generated files for performance optimization such as the route and services cache files.

The Config Directory

The config directory, as the name implies, contains all of your application's configuration files. It's a great idea to read through all of these files and familiarize yourself with all of the options available to you.

The Database Directory

The database directory contains your database migrations, model factories, and seeds. If you wish, you may also use this directory to hold an SQLite database.

The Public Directory

The public directory contains the index.php file, which is the entry point for all requests entering your application and configures autoloading. This directory also houses your assets such as images, JavaScript, and CSS.

The Resources Directory

The resources directory contains your views as well as your raw, un-compiled assets such as CSS or JavaScript.

The Routes Directory

The routes directory contains all of the route definitions for your application. By default, two route files are included with Laravel: web.php and console.php.

The web.php file contains routes that Laravel places in the web middleware group, which provides session state, CSRF protection, and cookie encryption. If your application does not offer a stateless, RESTful API then all your routes will most likely be defined in the web.php file.

The console.php file is where you may define all of your closure-based console commands. Each closure is bound to a command instance allowing a simple approach to interacting with each command's IO methods. Even though this file does not define HTTP routes, it defines console based entry points (routes) into your application. You may also schedule tasks in the console.php file.

Optionally, you may install additional route files for API routes (api.php) and broadcasting channels (channels.php), via the install:api and install:broadcasting Artisan commands.

The api.php file contains routes that are intended to be stateless, so requests entering the application through these routes are intended to be authenticated via tokens and will not have access to session state.

The channels.php file is where you may register all of the event broadcasting channels that your application supports.

The Storage Directory

The storage directory contains your logs, compiled Blade templates, file based sessions, file caches, and other files generated by the framework. This directory is segregated into app, framework, and logs directories. The app directory may be used to store any files generated by your application. The framework directory is used to store framework generated files and caches. Finally, the logs directory contains your application's log files.

The storage/app/public directory may be used to store user-generated files, such as profile avatars, that should be publicly accessible. You should create a symbolic link at public/storage which points to this directory. You may create the link using the php artisan storage:link Artisan command.

The Tests Directory

The tests directory contains your automated tests. Example Pest or PHPUnit unit tests and feature tests are provided out of the box. Each test class should be suffixed with the word Test. You may run your tests using the /vendor/bin/pest or /vendor/bin/phpunit commands. Or, if you would like a more detailed and beautiful representation of your test results, you may run your tests using the php artisan test Artisan command.

The Vendor Directory

The vendor directory contains your Composer dependencies.

The App Directory

The majority of your application is housed in the app directory. By default, this directory is namespaced under App and is autoloaded by Composer using the PSR-4 autoloading standard.

By default, the app directory contains the Http, Models, and Providers directories. However, over time, a variety of other directories will be generated inside the app directory as you use the make Artisan commands to generate classes. For example, the app/Console directory will not exist until you execute the make:command Artisan command to generate a command class.

Both the Console and Http directories are further explained in their respective sections below, but think of the Console and Http directories as providing an API into the core of your application. The HTTP protocol and CLI are both mechanisms to interact with your application, but do not actually contain application logic. In other words, they are two ways of issuing commands to your application. The Console directory contains all of your Artisan commands, while the Http directory contains your controllers, middleware, and requests.

[!NOTE]

Many of the classes in the app directory can be generated by Artisan via commands. To review the available commands, run the php artisan list make command in your terminal.

The Broadcasting Directory

The Broadcasting directory contains all of the broadcast channel classes for your application. These classes are generated using the make:channel command. This directory does not exist by default, but will be created for you when you create your first channel. To learn more about channels, check out the documentation on event broadcasting.

The Console Directory

The Console directory contains all of the custom Artisan commands for your application. These commands may be generated using the make:command command.

The Events Directory

This directory does not exist by default, but will be created for you by the event:generate and make:event Artisan commands. The Events directory houses event classes. Events may be used to alert other parts of your application that a given action has occurred, providing a great deal of flexibility and decoupling.

The Exceptions Directory

The Exceptions directory contains all of the custom exceptions for your application. These exceptions may be generated using the make:exception command.

The Http Directory

The Http directory contains your controllers, middleware, and form requests. Almost all of the logic to handle requests entering your application will be placed in this directory.

The Jobs Directory

This directory does not exist by default, but will be created for you if you execute the make:job Artisan command. The Jobs directory houses the queueable jobs for your application. Jobs may be queued by your application or run synchronously within the current request lifecycle. Jobs that run synchronously during the current request are sometimes referred to as "commands" since they are an implementation of the command pattern.

The Listeners Directory

This directory does not exist by default, but will be created for you if you execute the event:generate or make:listener Artisan commands. The Listeners directory contains the classes that handle your events. Event listeners receive an event instance and perform logic in response to the event being fired. For example, a UserRegistered event might be handled by a SendWelcomeEmail listener.

The Mail Directory

This directory does not exist by default, but will be created for you if you execute the make:mail Artisan command. The Mail directory contains all of your classes that represent emails sent by your application. Mail objects allow you to encapsulate all of the logic of building an email in a single, simple class that may be sent using the Mail::send method.

The Models Directory

The Models directory contains all of your Eloquent model classes. The Eloquent ORM included with Laravel provides a beautiful, simple ActiveRecord implementation for working with your database. Each database table has a corresponding "Model" which is used to interact with that table. Models allow you to query for data in your tables, as well as insert new records into the table.

The Notifications Directory

This directory does not exist by default, but will be created for you if you execute the make:notification Artisan command. The Notifications directory contains all of the "transactional" notifications that are sent by your application, such as simple notifications about events that happen within your application. Laravel's notification feature abstracts sending notifications over a variety of drivers such as email, Slack, SMS, or stored in a database.

The Policies Directory

This directory does not exist by default, but will be created for you if you execute the make:policy Artisan command. The Policies directory contains the authorization policy classes for your application. Policies are used to determine if a user can perform a given action against a resource.

The Providers Directory

The Providers directory contains all of the service providers for your application. Service providers bootstrap your application by binding services in the service container, registering events, or performing any other tasks to prepare your application for incoming requests.

In a fresh Laravel application, this directory will already contain the AppServiceProvider. You are free to add your own providers to this directory as needed.

The Rules Directory

This directory does not exist by default, but will be created for you if you execute the make:rule Artisan command. The Rules directory contains the custom validation rule objects for your application. Rules are used to encapsulate complicated validation logic in a simple object. For more information, check out the validation documentation.

مقدمه

ساختار پیش‌فرض اپلیکیشن‌های لاراول به گونه‌ای طراحی شده است که نقطه شروعی عالی برای پروژه‌های کوچک و بزرگ فراهم کند. با این حال، شما در سازماندهی ساختار اپلیکیشن خود کاملاً آزاد هستید. لاراول تقریباً هیچ محدودیتی برای محل قرارگیری کلاس‌ها اعمال نمی‌کند، تنها شرط این است که «کامپوزر» (Composer) بتواند کلاس مربوطه را به صورت خودکار بارگذاری (Autoload) کند.

دایرکتوری ریشه (Root Directory)

دایرکتوری app

دایرکتوری app شامل هسته اصلی کدهای اپلیکیشن شماست. در ادامه، این دایرکتوری را با جزئیات بیشتری بررسی خواهیم کرد؛ با این حال، باید بدانید که تقریباً تمام کلاس‌های اپلیکیشن شما در این دایرکتوری قرار خواهند گرفت.

دایرکتوری bootstrap

دایرکتوری bootstrap حاوی فایل app.php است که وظیفه راه‌اندازی (Bootstrap) فریم‌ورک را بر عهده دارد. همچنین این دایرکتوری شامل یک پوشه cache است که فایل‌های تولید شده توسط فریم‌ورک برای بهینه‌سازی عملکرد (مانند فایل‌های کشِ مسیرها و سرویس‌ها) در آن ذخیره می‌شوند.

دایرکتوری config

همان‌طور که از نام دایرکتوری config پیداست، این بخش شامل تمامی فایل‌های پیکربندی (Configuration files) اپلیکیشن شماست. پیشنهاد می‌کنم حتماً تمامی این فایل‌ها را مطالعه کنید تا با گزینه‌های مختلفی که در اختیار دارید، آشنا شوید.

دایرکتوری database

دایرکتوری database شامل مواردی همچون Database Migrations، Model Factories و Seeds است. در صورت تمایل، می‌توانید از این دایرکتوری برای نگهداری پایگاه‌داده SQLite نیز استفاده کنید.

دایرکتوری public

دایرکتوری public حاوی فایل index.php است که نقطه ورود (Entry point) برای تمامی درخواست‌های ارسالی به اپلیکیشن شما محسوب می‌شود و وظیفه پیکربندی Autoloading را بر عهده دارد. همچنین، دارایی‌های (Assets) پروژه از قبیل تصاویر، فایل‌های JavaScript و CSS در این دایرکتوری قرار می‌گیرند.

دایرکتوری resources

دایرکتوری resources شامل Views و همچنین دارایی‌های خام و کامپایل‌نشده (Raw, un-compiled assets) مانند فایل‌های CSS یا JavaScript است.

دایرکتوری routes

دایرکتوری routes شامل تمامی تعاریف مسیر (Route definitions) برای اپلیکیشن شماست. به طور پیش‌فرض، دو فایل مسیر در لاراول گنجانده شده است: web.php و console.php.

فایل web.php شامل مسیرهایی است که لاراول در گروه میان‌افزار (Middleware group) وب قرار می‌دهد؛ این گروه وضعیت نشست (Session state)، حفاظت CSRF و رمزنگاری کوکی (Cookie encryption) را فراهم می‌کند. اگر اپلیکیشن شما یک API مستقل و RESTful ارائه نمی‌دهد، به احتمال زیاد تمام مسیرهای شما در فایل web.php تعریف خواهند شد.

فایل console.php مکانی است که می‌توانید تمام دستورات کنسول مبتنی بر بستار (Closure-based console commands) خود را در آن تعریف کنید. هر بستار به یک نمونه فرمان (Command instance) پیوند داده می‌شود که رویکردی ساده برای تعامل با متدهای IO هر فرمان را امکان‌پذیر می‌سازد. اگرچه این فایل مسیرهای HTTP را تعریف نمی‌کند، اما نقاط ورود مبتنی بر کنسول (Console based entry points) (مسیرها) را به اپلیکیشن شما معرفی می‌کند. همچنین می‌توانید وظایف زمان‌بندی شده (Scheduled tasks) را در فایل console.php تعریف کنید.

به صورت اختیاری، می‌توانید فایل‌های مسیر اضافی برای مسیرهای API (api.php) و کانال‌های پخش (Broadcasting channels) (channels.php) را از طریق دستورات Artisan install:api و install:broadcasting نصب کنید.

فایل api.php شامل مسیرهایی است که برای حالت Stateless در نظر گرفته شده‌اند، بنابراین درخواست‌هایی که از طریق این مسیرها وارد اپلیکیشن می‌شوند، قرار است از طریق توکن‌ها (Tokens) احراز هویت شوند و به وضعیت نشست دسترسی نخواهند داشت.

فایل channels.php مکانی است که می‌توانید تمام کانال‌های پخش رویداد (Event broadcasting channels) را که اپلیکیشن شما پشتیبانی می‌کند، ثبت (Register) کنید.

دایرکتوری storage

دایرکتوری storage حاوی لاگ‌ها (Logs)، قالب‌های کامپایل‌شده Blade، نشست‌های مبتنی بر فایل (File based sessions)، کش‌های مبتنی بر فایل (File caches) و سایر فایل‌های تولید شده توسط فریم‌ورک است. این دایرکتوری به سه بخش app، framework و logs تقسیم شده است.

  • دایرکتوری app می‌تواند برای ذخیره هرگونه فایل تولید شده توسط اپلیکیشن شما استفاده شود.
  • دایرکتوری framework برای ذخیره فایل‌ها و کش‌های تولید شده توسط فریم‌ورک به کار می‌رود.
  • در نهایت، دایرکتوری logs حاوی فایل‌های لاگ اپلیکیشن شماست.

دایرکتوری storage/app/public ممکن است برای ذخیره فایل‌های تولید شده توسط کاربر، مانند آواتار پروفایل (Profile avatars) که باید به صورت عمومی قابل دسترسی باشند، استفاده شود. شما باید یک پیوند نمادین (Symbolic link) در public/storage ایجاد کنید که به این دایرکتوری اشاره کند. این پیوند را می‌توانید با استفاده از دستور Artisan php artisan storage:link ایجاد نمایید.

دایرکتوری tests

دایرکتوری tests شامل تست‌های خودکار (Automated tests) شماست. نمونه‌هایی از تست‌های واحد (Unit tests) و تست‌های ویژگی (Feature tests) با استفاده از Pest یا PHPUnit به صورت پیش‌فرض ارائه شده‌اند. نام هر کلاس تست باید با کلمه Test خاتمه یابد. شما می‌توانید تست‌های خود را با استفاده از دستورات /vendor/bin/pest یا /vendor/bin/phpunit اجرا کنید. همچنین، اگر به دنبال نمایش جزئی‌تر و زیباتر نتایج تست‌های خود هستید، می‌توانید تست‌ها را با استفاده از دستور Artisan php artisan test اجرا نمایید.

دایرکتوری vendor

دایرکتوری vendor حاوی وابستگی‌های Composer شماست.

دایرکتوری app

بخش عمده اپلیکیشن شما در دایرکتوری app قرار دارد. به طور پیش‌فرض، این دایرکتوری دارای نام‌فضای (Namespace) App است و توسط Composer با استفاده از استاندارد بارگذاری خودکار PSR-4 بارگذاری می‌شود.

به طور پیش‌فرض، دایرکتوری app شامل زیردایرکتوری‌های Http، Models و Providers است. با این حال، با گذشت زمان و استفاده از دستورات Artisan make برای ایجاد کلاس‌ها، دایرکتوری‌های مختلفی درون app ایجاد خواهند شد. به عنوان مثال، دایرکتوری app/Console تا زمانی که دستور make:command Artisan را برای ایجاد یک کلاس دستور اجرا نکنید، وجود نخواهد داشت.

هر دو دایرکتوری Console و Http در بخش‌های مربوط به خود در ادامه به تفصیل توضیح داده شده‌اند. با این حال، این دایرکتوری‌ها را به عنوان رابطی (API) به هسته اصلی اپلیکیشن خود در نظر بگیرید. پروتکل HTTP و CLI هر دو مکانیزم‌هایی برای تعامل با اپلیکیشن شما هستند، اما منطق اصلی اپلیکیشن را در خود جای نمی‌دهند. به عبارت دیگر، این دو روش برای صدور دستور به اپلیکیشن شما محسوب می‌شوند. دایرکتوری Console شامل تمامی دستورات Artisan شماست، در حالی که دایرکتوری Http شامل کنترلرها (Controllers)، میان‌افزارها (Middleware) و درخواست‌ها (Requests) است.

نکته: بسیاری از کلاس‌های موجود در دایرکتوری app را می‌توان از طریق دستورات Artisan ایجاد کرد. برای مشاهده دستورات موجود، دستور php artisan list make را در ترمینال خود اجرا کنید.

دایرکتوری Broadcasting

دایرکتوری Broadcasting حاوی تمامی کلاس‌های کانال پخش (Broadcast channel classes) اپلیکیشن شماست. این کلاس‌ها با استفاده از دستور make:channel ایجاد می‌شوند. این دایرکتوری به صورت پیش‌فرض وجود ندارد، اما هنگامی که اولین کانال خود را ایجاد کنید، برای شما ساخته خواهد شد. برای اطلاعات بیشتر در مورد کانال‌ها، مستندات مربوط به پخش رویداد (Event broadcasting) را مطالعه کنید.

دایرکتوری Console

دایرکتوری Console حاوی تمامی دستورات سفارشی Artisan برای اپلیکیشن شماست. این دستورات را می‌توان با استفاده از دستور make:command ایجاد کرد.

دایرکتوری Events

این دایرکتوری به صورت پیش‌فرض وجود ندارد، اما توسط دستورات Artisan event:generate و make:event برای شما ایجاد خواهد شد. دایرکتوری Events کلاس‌های رویداد (Event classes) را در خود جای می‌دهد. رویدادها می‌توانند برای اطلاع‌رسانی به سایر بخش‌های اپلیکیشن شما مبنی بر وقوع یک عمل خاص استفاده شوند، که این امر انعطاف‌پذیری و جداسازی (Decoupling) بالایی را فراهم می‌کند.

دایرکتوری Exceptions

دایرکتوری Exceptions حاوی تمامی استثنائات سفارشی (Custom exceptions) اپلیکیشن شماست. این استثنائات را می‌توان با استفاده از دستور make:exception ایجاد کرد.

دایرکتوری Http

دایرکتوری Http شامل کنترلرها (Controllers)، میان‌افزارها (Middleware) و درخواست‌های فرم (Form requests) شماست. تقریباً تمام منطق مربوط به پردازش درخواست‌هایی که وارد اپلیکیشن شما می‌شوند، در این دایرکتوری قرار می‌گیرد.

دایرکتوری Jobs

این دایرکتوری به صورت پیش‌فرض وجود ندارد، اما اگر دستور Artisan make:job را اجرا کنید، برای شما ایجاد خواهد شد. دایرکتوری Jobs وظایف قابل صف‌بندی (Queueable jobs) اپلیکیشن شما را در خود جای می‌دهد. این وظایف می‌توانند توسط اپلیکیشن شما در صف قرار گیرند یا به صورت همزمان (Synchronously) در طول چرخه عمر درخواست فعلی اجرا شوند. وظایفی که به صورت همزمان در طول درخواست فعلی اجرا می‌شوند، گاهی اوقات "دستورات" (Commands) نامیده می‌شوند، زیرا پیاده‌سازی الگوی Command هستند.

دایرکتوری Listeners

این دایرکتوری به صورت پیش‌فرض وجود ندارد، اما اگر دستورات Artisan event:generate یا make:listener را اجرا کنید، برای شما ایجاد خواهد شد. دایرکتوری Listeners شامل کلاس‌هایی است که رویدادهای شما را مدیریت می‌کنند. شنونده‌های رویداد (Event listeners) یک نمونه رویداد دریافت کرده و در پاسخ به فعال شدن رویداد، منطقی را اجرا می‌کنند. به عنوان مثال، رویداد UserRegistered ممکن است توسط شنونده SendWelcomeEmail مدیریت شود.

دایرکتوری Mail

این دایرکتوری به صورت پیش‌فرض وجود ندارد، اما اگر دستور Artisan make:mail را اجرا کنید، برای شما ایجاد خواهد شد. دایرکتوری Mail حاوی تمام کلاس‌هایی است که نماینده ایمیل‌های ارسال شده توسط اپلیکیشن شما هستند. اشیاء Mail به شما این امکان را می‌دهند که تمام منطق ساخت یک ایمیل را در یک کلاس واحد و ساده کپسوله کنید که می‌تواند با استفاده از متد Mail::send ارسال شود.

دایرکتوری Models

دایرکتوری Models شامل تمام کلاس‌های مدل Eloquent شماست. Eloquent ORM که در لاراول گنجانده شده است، یک پیاده‌سازی زیب و ساده ActiveRecord برای کار با پایگاه داده شما ارائه می‌دهد. هر جدول پایگاه داده دارای یک "مدل" (Model) متناظر است که برای تعامل با آن جدول استفاده می‌شود. مدل‌ها به شما این امکان را می‌دهند که داده‌های جداول خود را جستجو کرده و همچنین رکوردهای جدیدی را در جدول درج کنید.

دایرکتوری Notifications

این دایرکتوری به صورت پیش‌فرض وجود ندارد، اما اگر دستور Artisan make:notification را اجرا کنید، برای شما ایجاد خواهد شد. دایرکتوری Notifications حاوی تمام اعلان‌های "تراکنشی" (Transactional notifications) است که توسط اپلیکیشن شما ارسال می‌شوند، مانند اعلان‌های ساده درباره رویدادهایی که در اپلیکیشن شما رخ می‌دهند. ویژگی اعلان لاراول، ارسال اعلان‌ها را از طریق درایورهای مختلفی مانند ایمیل، اسلک (Slack)، پیامک (SMS) یا ذخیره در پایگاه داده، انتزاع می‌کند.

دایرکتوری Policies

این دایرکتوری به صورت پیش‌فرض وجود ندارد، اما اگر دستور Artisan make:policy را اجرا کنید، برای شما ایجاد خواهد شد. دایرکتوری Policies حاوی کلاس‌های سیاست احراز هویت (Authorization policy classes) برای اپلیکیشن شماست. سیاست‌ها برای تعیین اینکه آیا کاربر می‌تواند عملی مشخصی را بر روی یک منبع انجام دهد، استفاده می‌شوند.

دایرکتوری Providers

دایرکتوری Providers حاوی تمام ارائه‌دهندگان سرویس (Service providers) اپلیکیشن شماست. ارائه‌دهندگان سرویس با اتصال سرویس‌ها در کانتینر سرویس (Service container)، ثبت رویدادها یا انجام هرگونه وظایف دیگر برای آماده‌سازی اپلیکیشن شما برای درخواست‌های ورودی، اپلیکیشن شما را راه‌اندازی (Bootstrap) می‌کنند.

در یک اپلیکیشن تازه لاراول، این دایرکتوری از قبل حاوی AppServiceProvider خواهد بود. شما آزاد هستید که در صورت نیاز، ارائه‌دهندگان سرویس خود را به این دایرکتوری اضافه کنید.

دایرکتوری Rules

این دایرکتوری به صورت پیش‌فرض وجود ندارد، اما اگر دستور Artisan make:rule را اجرا کنید، برای شما ایجاد خواهد شد. دایرکتوری Rules حاوی اشیاء سفارشی قانون اعتبارسنجی (Custom validation rule objects) برای اپلیکیشن شماست. قوانین برای کپسوله کردن منطق پیچیده اعتبارسنجی در یک شیء ساده استفاده می‌شوند. برای اطلاعات بیشتر، مستندات اعتبارسنجی (Validation documentation) را بررسی کنید.