Laravel框架开发实践

Laravel是一款优秀的PHP框架，它的流行不仅仅是因为它的优秀特性，而且它开创了一种全新的编程思路，帮助开发者更加高效地完成Web应用的开发。在学习Laravel开发过程中，我深刻体会到了Laravel框架的简洁、高效和灵活，下面是我的学习心得和总结。

一、编程思路

1. Laravel基于MVC设计模式

 Laravel框架基于MVC设计模式，MVC是一种将应用程序的逻辑层分离出来的设计模式，将数据、显示和用户请求分离开来，各自职责明确。这种设计模式让Laravel框架更具有可扩展性、可维护性和可测试性。

2. 命令行工具

Laravel框架的命令行工具--“Artisan”可以帮助开发者快速的生成代码，减少开发过程中的重复代码，提升开发效率。例如，使用“make:model”命令生成一个新的数据模型，使用“make:controller”命令生成一个新的控制器，可以减少开发人员不必要的繁琐工作。同时，“Artisan”提供了丰富的命令行工具，可以帮助开发者快速调试应用程序，提高开发效率。

3. Composer

Laravel使用Composer管理依赖关系，通过使用Composer，开发者不必担心手动管理PHP类库的依赖关系，让开发者专注于业务逻辑的实现，同时可以节省开发时间和维护成本。

二、技巧运用

1. 中间件

中间件在Laravel框架中扮演了很重要的角色，可以实现对HTTP请求的预处理，例如鉴权、记录日志、参数验证等。中间件采用MVC设计模式，让代码分离的更加清晰，让系统更加健壮可靠。

2. Blade模板引擎

Laravel框架中强大的Blade模板引擎，可以让开发者更轻松地进行前端开发。Blade模板引擎提供丰富的模板语法，支持if语句、foreach循环等常用的语法，让前端排版更加直观简单，同时也可以降低前后端分离的开发成本。

3. Eloquent ORM

Laravel框架中的Eloquent ORM提供了非常强大的数据处理能力，代码简洁易懂。ORM将数据库中表的操作转换为对象的操作，让开发者不必直接操作数据库，大大简化了代码的编写和维护。

三、软件工程类学习体会

1. 单一职责原则

在使用Laravel框架时，我们要注意遵守单一职责原则，使得每一个类和函数都只有单一的职责。这样可以保证代码的可读性，也方便进行单元测试以及代码得复用。

2. 依赖注入原则

当我们在开发Laravel应用时，我们会发现Laravel框架完全支持依赖注入原则，所有的依赖注入和实例化都可以由Laravel容器完成。这样开发者只需要注重开发业务逻辑，而不需要关注类的实例化以及依赖的实现，降低了代码的耦合性，也方便横向扩展和单元测试。

3. 设计模式

Laravel框架完全支持常见的23种设计模式，例如Factory, Decorator, Observer等。在实际开发中，我们可以运用合适得设计模式，更好地完成动态拓展，提高代码质量和可维护性。

四、项目总结与分析

在实际应用中，我曾使用Laravel框架开发了一个在线的购物系统。该系统支持用户注册、商品浏览、购物车、订购、商品评价等功能，使用Laravel框架和Bootstrap前端框架。在该项目中，我深刻的感受到了Laravel框架的优秀特性，并对开源框架的开发、封装有了更深的体会。

总而言之，Laraval框架是一款功能强大、易扩展并且具有高性能的PHP框架，堪称PHP语言的一大福音。本次Laravel框架开发实践中，我以自身的体验结合实际项目经验，分享了Laravel框架的编程思路、技巧运用、软件工程类学习体会和项目总结等方面的内容。我相信，掌握Laravel框架将会在PHP开发领域更加得心应手，对提升职业竞争力有极强的帮助。

Laravel 是一个非常流行的 PHP 框架，我们可以使用它快速构建一个 WEB 应用程序。而现在 WEB 应用中多会采用前后端分离技术，所以我们经常会遇到使用 Laravel 搭建 API 项目的需求。 Laravel 在提供 API 这方面，很多地方都只是提供了一个规范，并没有告诉我们如何去实现它。这样带来的好处是 Laravel 放开了限制，使大家可以按照自己的习惯去使用它。 但这样做也给刚接触 Laravel 不久的同学带来了一些困扰：到底怎样使用这个框架才更优雅些呢，有没有例子可以参考下呢。

本项目就是为了给大家提供一个参考而建立的，这是一个使用 Laravel 框架实现的 API 项目，项目中提供了一些常见功能的示例。 本项目从零开始，在重要修改部分末尾都会添加 [commit] 链接, 可自行查看变更记录。

需要注意的是：

1. 这并不是一个 Laravel 的新手教程，文中很多地方需要你了解 Laravel 的基础知识。 Laravel官网文档
2. 如果你已经有自己的实现方式，可以略过此教程，这个项目的实现方式可能也没比你的实现方式更优雅。
3. Laravel 各个版本之前实现方式还是有一些区别的，要注意区分，但整体思路是一样的。

安装

这里使用 composer 安装 Laravel ，下面命令会安装最新版本的 Laravel 。此项目创建时的 Laravel 版本为 v8.21.0

composer create-project --prefer-dist laravel/laravel laravel-api-example

安装好之后需要自行配置项目使其可以对外访问，当在浏览器中输入项目地址进入到 Laravel 的欢迎页时，就可以继续向下阅读了。

路由

在欢迎页我们可以看到，Laravel 返回的信息是一个 web 页面，也就是 html 代码。这个默认的路由是在 routes/web.php 中定义的，我们需要把它给移除掉。[commit]

我们所有的路由都要定义到 routes/api.php 中，这个是专门用来定义 API 路由的文件，当然如果你的路由特别多你也可以在 routes 中定义其他路由文件，然后在 RouteServiceProvider 中按照同样的方式去加载它们。 在 RouteServiceProvider 中我们可以看到，我们在 routes/api.php 中定义的路由会默认加上 api 前缀，这对 WEB 和 API 混写在同一个项目中很有必要，但单独的 API 项目一般也会单独域名。如：

https://api.apihubs.cn/holiday/get

所以我们要移除这个 api 前缀或换成其他前缀如接口版本号 V1 [commit]

在 routes/api.php 中默认的路由是一个需要身份验证的 /user

我们使用浏览器或 postman 访问的时候，会得到一个错误页面,其中的主要信息为：Route [login] not defined.

我们使用 ajax 或者在 postman 的 header 中添加 X-Requested-With:XMLHttpRequest 头信息后又会得到一个 JSON 的错误信息：{"message": "Unauthenticated."}

这实际上都是未登录的原因，在未登录访问需要鉴权的接口时 Laravel 会抛出一个 AuthenticationException ，而在响应类 Response 中会根据请求的 header 头自动做出响应。 也就是如果是以页面形式调用的，就会跳转到登录页面，因为项目中还没定义登录页面的路由就出现我们上面看到的那个错误。如果是以接口形式访问的就会 401 状态码并返回 JSON 信息。

但我们这是一个 API 项目，提供出去的都是接口地址，在接口地址中一会返回 JSON 一会又返回一个页面这是不是显得很尴尬。

这里我们需要新增一个 Middleware 来解决这个问题。然后在 Kernel 中注册这个 Middleware 使其全局生效。 [commit]

php artisan make:middleware JsonApplication

这样我们已经配置好一个 JSON 应用了，在 Laravel 抛出任何异常时，无论我们以什么方式访问都会始终得到 JSON 响应信息。

需要注意的是我们依然不能在路由的闭包或控制器中使用 ~~return view($view)~~ ，因为这会强制返回一个 html 页面响应。 我们应该在路由的闭包或控制器中始终 return 一个对象或数组，这两种格式会使 Laravel 自动为我们返回正确的 JSON 信息。

错误码

通过上面的配置，我们的应用可以始终返回 JSON 信息了。比如在出现异常的时候：

• 鉴权失败会返回 http 状态码 401 的 {"message": "Unauthenticated."}
• 请求的 method 不正确会返回 http 状态码 405 的 {"message":"The POST method is not supported for this route. Supported methods: GET, HEAD.","exception":"Symfony\Component\HttpKernel\Exception\MethodNotAllowedHttpException",...}
• 请求的 URL 地址不存在会返回 404 的 {"message":"","exception":"Symfony\Component\HttpKernel\Exception\NotFoundHttpException",...}
• ...

但这样的返回信息也有问题：

1. 返回信息的格式并不统一，JSON 中的 key 时有时无，接口调用方在很多时候找不到要以什么作为依据进行判断
2. 许多异常信息为服务端敏感信息，会直接报漏给用户，存在安全隐患
3. 异常信息都是通过 HTTP 状态码抛出的，会导致许多错误的 HTTP 状态码相同，比如 500

而通常的做法是需要根据不同的业务场景定义不同的错误代码和错误信息, 然后始终返会 http 状态码 200 的 {"code":"","msg":"","data":""}

在这里我们需要引入一个第三方的库（这个库会在项目中许多地方使用，也是本教程的核心，当然这个库的功能是仿照 Java 枚举而来的） phpenum 。 [commit]

composer require phpenum/phpenum

这是一个枚举库，在这里用来定义和管理错误码和错误信息，错误码的位数应该是固定的，至少一个模块下的错误码位数是固定的，这里使用 5 位错误码，你可以根据实际使用场景来定义。 我们在 app 目录下新建一个 Enums 目录，然后添加 ErrorEnum 为不同的错误和异常定义不同的错误码。 [commit]

定义好错误码后，我们还需要借助 Laravel 的 渲染异常 来渲染自定义异常类 ApiException 。 [commit]

php artisan make:exception ApiException

在上面这个 commit 中，我们对常见的异常都做了处理，使他们返回固定的错误码和错误信息，尤其对数据验证失败在 data 中返回了详细的错误信息，你也可以在 Handler 中添加一些其他需要处理的异常。

而未特殊定义状态码的异常会统一返回错误码 99999 的 未知错误，生产环境中是不应该出现这个错误码的，这个异常一般出现在调试阶段，我们需要解决掉它。

由于接口不再返回任何错误信息了，我们排查问题的方式也只能通过日志来排查 默认的日志在你本地的这个目录下 Laravel的日志也是非常强大，你可以随意更改存储的位置和介质，这里就不展开介绍了。

到这里我们就配置好统一错误码了，接下来无论在项目中出现什么错误，抛出什么异常，接口返回的信息始终保持为http状态码200的 {"code":"","msg":"","data":""}

但这些状态码都是系统产生异常时返回的，我们要自己返回自定义状态码要怎么做呢? 非常简单，你只需要在任何你想返回自定义状态码的地方抛出自定义异常就可以了（但除了 controller 层，其他层可能会以非 web 的方式掉用，比如 console ，它不应该捕获到 ApiException ，所以尽量保证在 control