Directory Structure
brief introduction
Laravel's default directory structure attempts to provide a good starting point for both large and small applications. Of course, you can also reorganize the directory structure of the application according to your own preferences, because Larvel has no restrictions on where the specified classes are loaded -- as long as Composer can automatically load them.
Where is the Models directory?
Many beginners may wonder why Laravel didn't provide models The official explanation of the catalogue is that different people models The meaning of this word is different, which is easy to cause ambiguity. Some developers think that the application model refers to business logic, while others think that the model refers to the interaction with the associated database. For this reason, the official default is to place Eloquent's model directly into app Directory, let the developer choose the location of the model.
This is the idea of the author of the Laravel framework, but for domestic developers, especially PHP developers, models The directory is used to store the model classes that interact with the database. There should be no objection, but the business logic should be placed in services This directory. Therefore, it is recommended that you specify to generate model classes to app/Models Under the directory:
php artisan make:model Models/Test

root directory
App Directory
app The directory contains the core code of the application. Note that it is not the core code of the framework. The core code of the framework is in the /vendor/laravel/framework In addition, most of the code you write for the application will also be placed here. Of course, if you do PHP component-based development based on Composer, there may only be some entry-level code stored here;
Bootstrap directory
bootstrap The directory contains a few files for the startup and automatic loading configuration of the framework. There is also a cache Folder, which contains files generated by the framework to improve performance, such as routing and service cache files;
Config directory
config The directory contains all the configuration files of the application. It is recommended to read through these configuration files to familiarize yourself with all the default configuration items of Larave;
Database directory
database The directory contains database migration files and fill files. If SQLite is used, you can also use it as the directory for storing SQLite databases;
Public Directory
public The directory contains the application entry file index.php And front-end resource files (pictures JavaScript, CSS, etc.), which is also the application root directory pointed to by Apache or Nginx and other Web servers. The advantage of this is that it isolates the core application files from being directly exposed under the Web root directory. If the permission system is not well prepared or the server configuration is vulnerable, it is likely to lead to the theft of application sensitive files by hackers, thereby posing a threat to website security;
Resources directory
resources The directory contains application view files and uncompiled native front-end resource files (LESS SASS、JavaScript）， And localized language files;
Routes directory
routes The directory contains all routes defined by the application. Laravel provides four routing files by default for different portals: web.php 、 api.php 、 console.php and channels.php 。
web.php All the routes contained in the file are located in RouteServiceProvider Defined web It is within the constraints of the middleware group, so it supports session, CSRF protection and cookie encryption functions. If the application does not need to provide stateless, RESTful style APIs, then the route should basically be defined in web.php File.
api.php The file contains routes located at api Within the constraints of the middleware group, the function of frequency restriction is supported. These routes are stateless, so requests to enter the application through these routes need to be authenticated through the token and cannot access the session state.
console.php The file is used to define all console commands based on closures. Each closure is bound to a console command and allows interaction with command line IO methods. Although this file does not define HTTP routes, it defines console based application portals (routes).
channels The file is used to register all event broadcast channels supported by the application.
Storage directory
storage The directory contains compiled Blade templates, file based sessions, file caches, and other files generated by the framework. The directory is subdivided into app 、 framework and logs Subdirectory, app The directory is used to store files generated by applications, framework The directory is used to store files and caches generated by the framework. Finally, logs The directory stores the application log files.
storage/app/public The directory is used to store user generated files, such as user avatars that can be publicly accessed. To be accessed by Web users, you also need to public (under the application root directory public Directory) Generate a soft connection under the directory storage Point to this directory. You can php artisan storage:link The command generates this soft link.
Tests directory
tests The directory contains automated test files, in which an out of the box PHPUnit Examples; Each test class should be Test At the beginning, you can use phpunit or php vendor/bin/phpunit Command to run the test.
Vendor Catalog
vendor The directory contains all applications passed Composer Loaded dependencies.
App Directory
The core code of the application is located in app Directory. By default, the directory is in the namespace App And passed by Composer PSR-4 automatic loading standard Automatic loading. app The directory contains multiple subdirectories, such as Console 、 Http 、 Providers Etc. Console and Http The directory provides an API to access the application core. HTTP protocol and CLI are two mechanisms for interaction with applications, but they do not actually contain application logic. In other words, they are just two ways to send commands to applications. Console The directory contains all Artisan commands written by developers, Http The directory contains the controller, middleware, request, etc.
Other directories will be displayed in the Artisan command make Automatically generated to app Directory. For example, app/Jobs Directory until you execute make:job Only when the command generates the task class will it appear in the app Directory.
Note: app Many classes in the directory can be generated through Artisan commands. To view all valid commands, you can run them in the terminal php artisan list make Command.
Console directory
Console The directory contains all customized Artisan commands that can be used make:command Command generation. There are also Console/Kernel Class, where you can register user-defined Artisan commands and define scheduling tasks.
Events directory
This directory does not exist by default, but can be accessed through event:generate and make:event Command creation. This directory is used to store event classes. The event class is used to inform other parts of the application of the occurrence of an event and provide a flexible and decoupled processing mechanism.
Exceptions directory
Exceptions The directory contains the exception handler of the application, and is also a good place to handle any exceptions thrown by the application.
Http directory
Http The directory contains controllers, middleware, form requests, etc. Almost all requests entering applications via the Web are processed here.
Jobs directory
This directory does not exist by default. You can execute make:job Command generation, Jobs The directory is used to store queue tasks. The tasks in the application can be Push to queue , or it can be executed synchronously within the current request lifecycle. Tasks executed synchronously are sometimes regarded as commands because they implement Command mode 。
Listeners directory
This directory does not exist by default. You can execute event:generate and make:listener Command creation. Listeners The directory contains classes (event listeners) that handle events. The event listener receives an event and provides response logic after the event occurs, for example, UserRegistered Events can be SendWelcomeEmail Listener processing.
Mail Directory
This directory does not exist by default, but can be executed by make:mail Command generation, Mail The directory contains all the mail related classes of the application. The mail object allows you to encapsulate all the business logic needed to build the mail in one place, and then use Mail::send Method to send mail.
Notifications directory
This directory does not exist by default. You can execute make:notification Commands are created jointly, Notifications The directory contains all the notifications sent by the application, such as event occurrence notifications. Larave's notification function decouples notification sending and notification driving. You can send notifications via email, Slack, SMS or database.
Policies Directory
This directory does not exist by default. You can execute make:policy Command to generate a policy class to create, Policies The directory contains all the authorization policy classes of the application. The policy is used to determine whether a user has permission to access the specified resources. For more details, please check Authorization Document 。
Providers directory
Providers The directory contains all the applied Service Provider 。 The service provider binds services to the container, registers events, and performs other tasks during the application startup process to prepare for the upcoming request processing.
In the newly installed Larravel application, this directory already contains some service providers. You can add your own service providers to this directory as needed.
Rules directory
This directory does not exist by default, but it will accompany you to execute Artisan commands make:rule Automatically generated. Rules The directory contains the applied custom validation rule objects. These rules are used to encapsulate complex validation logic in a single object. For more information, please refer to Validate Document 。
