一种颗粒度很小的 Laravel 路由文件划分方式(翻译)
我估计我们所有人都遇到过这样的情况,即我们有一个写满路由的超大文件。不骗你,这让我很长一段时间几近抓狂,我不得不想个办法解决这个问题。 因此,这就是我最终用来构造路由文件的方法。
推荐教程:《laravel教程》
最初,我想到了利用路由组方法可以接收文件,这就是 laravel 在 RouteServiceProvider 处拆分路由的方式。
<?php namespace App\Providers; use Illuminate\Foundation\Support\Providers\RouteServiceProvider as ServiceProvider; use Illuminate\Support\Facades\Route; class RouteServiceProvider extends ServiceProvider { /** * This namespace is applied to your controller routes. * * In addition, it is set as the URL generator's root namespace. * * @var string */ protected $namespace = 'App\Http\Controllers'; /** * Define your route model bindings, pattern filters, etc. * * @return void */ public function boot() { // parent::boot(); } /** * Define the routes for the application. * * @return void */ public function map() { $this->mapApiRoutes(); $this->mapWebRoutes(); // } /** * Define the "web" routes for the application. * * These routes all receive session state, CSRF protection, etc. * * @return void */ protected function mapWebRoutes() { Route::middleware('web') ->namespace($this->namespace) ->group(base_path('routes/web.php')); } /** * Define the "api" routes for the application. * * These routes are typically stateless. * * @return void */ protected function mapApiRoutes() { Route::prefix('api') ->middleware('api') ->namespace($this->namespace) ->group(base_path('routes/api.php')); } }
我将与用户有关的路由抽象到了一个名为 users.php 的文件中,并将 mapApiRoutes 复制为 mapUsersRoutes 并指向到我的 users.php 文件。
/** * Define the routes for the application. * * @return void */ public function map() { $this->mapApiRoutes(); $this->mapWebRoutes(); $this->mapUsersRoutes(); // } /** * Define the "api" routes for the application. * * These routes are typically stateless. * * @return void */ protected function mapUsersRoutes() { Route::prefix('api') ->middleware('api') ->namespace($this->namespace) ->group(base_path('routes/users.php')); }
我知道您在想什么,显然,这并不是最好的解决方案,因为每当我们需要创建新文件时,都必须像之前一样注册它。 因此,我不得不改进这个最初的想法。
我想到了将整个应用程序中的公共部分拆分成单独的路由文件,并且我想到我们的所有路由都不能超出已认证、访客和公共路由的范围。
我将路由文件夹的结构优化成下面这样:
├── routes │ ├── api │ │ ├── public │ | │ ├── users.php │ │ ├── auth │ | │ ├── users.php │ │ ├── guest │ | │ ├── users.php
乍一看,您可能会认为 “嗯,它并没有太大变化,我们还是需要去映射这些文件”。 但是,实际上我们可以利用 php 原生提供的名为 glob 的函数,这是一种开箱即用的解决方案,因为我们没有与 laravel 的解决方案耦合。
glob 接收一个正则,并且可以在与我们的正则匹配的路径下找到文件名。 因此,我们的路由是在特定文件夹下组织的,我们现在可以在这些文件夹下找到所有文件,并将它们注册到其中间件。
<?php namespace App\Providers; use Illuminate\Foundation\Support\Providers\RouteServiceProvider as ServiceProvider; use Illuminate\Support\Facades\Route; class RouteServiceProvider extends ServiceProvider { /** * This namespace is applied to your controller routes. * * In addition, it is set as the URL generator's root namespace. * * @var string */ protected $namespace = 'App\Http\Controllers'; /** * Define the routes for the application. * * @return void */ public function map() { $this->mapAuthRoutes(); $this->mapGuestRoutes(); $this->mapPublicRoutes(); // $this->mapWebRoutes(); // } /** * Define the "web" routes for the application. * * These routes all receive session state, CSRF protection, etc. * * @return void */ protected function mapWebRoutes() { Route::middleware('web') ->namespace($this->namespace) ->group(base_path('routes/web.php')); } /** * Define the "api" routes for the application. * * These routes are typically stateless. * * @return void */ protected function mapAuthRoutes() { foreach (glob(base_path('routes/api/auth/*.php')) as $file) { Route::prefix('api') ->middleware(['api', 'auth:api']) ->group($file); } } protected function mapGuestRoutes() { foreach (glob(base_path('routes/api/guest/*.php')) as $file) { Route::prefix('api') ->middleware(['api', 'guest:api']) ->group($file); } } protected function mapPublicRoutes() { foreach (glob(base_path('routes/api/public/*.php')) as $file) { Route::prefix('api') ->middleware('api') ->group($file); } } }
现在,无论何时我们创建一个新文件,foreach 都将找到它,因为它是使用正则匹配(该文件位于对应的路径下,并且具有 PHP 扩展名,因此它与我们的正则匹配)。简直太骚了!但是请稍等片刻。
这些文件将如何注册?
如果您研究过 laravel 的生命周期,您就知道服务提供者是 laravel 请求的生命周期的一部分,我们可以利用此功能动态注册我们的路线。
就是这样!我希望您喜欢它。
原文地址:https://dev.to/secmohammed/how-to-separa...
译文地址:https://learnku.com/laravel/t/42989
以上是一种颗粒度很小的 Laravel 路由文件划分方式(翻译)的详细内容。更多信息请关注PHP中文网其他相关文章!

热AI工具

Undresser.AI Undress
人工智能驱动的应用程序,用于创建逼真的裸体照片

AI Clothes Remover
用于从照片中去除衣服的在线人工智能工具。

Undress AI Tool
免费脱衣服图片

Clothoff.io
AI脱衣机

AI Hentai Generator
免费生成ai无尽的。

热门文章

热工具

记事本++7.3.1
好用且免费的代码编辑器

SublimeText3汉化版
中文版,非常好用

禅工作室 13.0.1
功能强大的PHP集成开发环境

Dreamweaver CS6
视觉化网页开发工具

SublimeText3 Mac版
神级代码编辑软件(SublimeText3)

PHP和Flutter是移动端开发的流行技术。Flutter胜在跨平台能力、性能和用户界面,适合需要高性能、跨平台和自定义UI的应用程序。PHP则适用于性能较低、不跨平台的服务器端应用程序。

使用ORM可简化PHP中的数据库操作,它将对象映射到关系数据库中。Laravel中的EloquentORM允许使用面向对象的语法与数据库交互,可通过定义模型类、使用Eloquent方法或在实战中构建博客系统等方式来使用ORM。

PHP单元测试工具分析:PHPUnit:适用于大型项目,提供全面功能,易于安装,但可能冗长且速度较慢。PHPUnitWrapper:适合小型项目,易于使用,针对Lumen/Laravel优化,但功能受限,不提供代码覆盖率分析,社区支持有限。

Laravel - Artisan 命令 - Laravel 5.7 提供了处理和测试新命令的新方法。它包括测试 artisan 命令的新功能,下面提到了演示?

Laravel9和CodeIgniter4的最新版本提供了更新的特性和改进。Laravel9采用MVC架构,提供数据库迁移、身份验证和模板引擎等功能。CodeIgniter4采用HMVC架构,提供路由、ORM和缓存。在性能方面,Laravel9的基于服务提供者设计模式和CodeIgniter4的轻量级框架使其具有出色的性能。在实际应用中,Laravel9适用于需要灵活性和强大功能的复杂项目,而CodeIgniter4适用于快速开发和小型应用程序。

比较Laravel和CodeIgniter的数据处理能力:ORM:Laravel使用EloquentORM,提供类对象关系映射,而CodeIgniter使用ActiveRecord,将数据库模型表示为PHP类的子类。查询构建器:Laravel具有灵活的链式查询API,而CodeIgniter的查询构建器更简单,基于数组。数据验证:Laravel提供了一个Validator类,支持自定义验证规则,而CodeIgniter的验证功能内置较少,需要手动编码自定义规则。实战案例:用户注册示例展示了Lar

PHP单元和集成测试指南单元测试:关注单个代码单元或函数,使用PHPUnit创建测试用例类进行验证。集成测试:关注多个代码单元协同工作的情况,使用PHPUnit的setUp()和tearDown()方法设置和清理测试环境。实战案例:使用PHPUnit在Laravel应用中进行单元和集成测试,包括创建数据库、启动服务器以及编写测试代码。

对于初学者来说,CodeIgniter的学习曲线更平缓,功能较少,但涵盖了基本需求。Laravel提供了更广泛的功能集,但学习曲线稍陡。在性能方面,Laravel和CodeIgniter都表现出色。Laravel具有更广泛的文档和活跃的社区支持,而CodeIgniter更简单、轻量级,具有强大的安全功能。在建立博客应用程序的实战案例中,Laravel的EloquentORM简化了数据操作,而CodeIgniter需要更多的手动配置。
