Laravel 2018使用数据分析——Laravel你用对了吗？学对了吗？

时间  2019-11-30
标签 laravel 使用 数据 分析 对了 繁體版
原文   原文链接

本文所说的Laravel 2018使用数据分析，指的是Laravel Shift的做者Jason McCreary，基于使用Laravel Shift的超过8000个laravel应用所作的分析。（Laravel Shift是一个自动升级你的laravel版本的付费应用，好比你的项目版本是5.1,使用它呢能够自动给你升级到5.6,这期间省去你手动升级的繁琐和烦恼。）php

更好的阅读体验请移步：www.pilishen.com/posts/larav…html

截至到2018年7月，Laravel Shift里有超过8500个上传的laravel apps，每一次版本的升级，Laravel Shift都会生成一个日志文件以用于debug，基于这些日志文件，产生了今天咱们提到的laravel使用数据。下面是Laravel Shift里日志文件一瞥：前端

*** _Shift_ version: 0281cff03fee62f250253f1e485dc7a790209866
*** Cloning app...

>>> _Shift_ 5.2 Event: app did not contain references to SelfHandling
>>> _Shift_ 5.2 Event: could not upgrade middleware Data: ["app\/Http\/Middleware\/Authenticate.php","app\/Http\/Middleware\/EncryptCookies.php","app\/Http\/Middleware\/RedirectIfAuthenticated.php"]
>>> _Shift_ 5.2 Event: could not upgrade app/Providers/RouteServiceProvider.php
>>> _Shift_ 5.2 Event: could not patch app/Providers/RouteServiceProvider.php
>>> _Shift_ 5.2 Event: could not find User model path
>>> _Shift_ 5.2 Event: found additional uses of Event names
>>> _Shift_ 5.2 Event: matched core file: phpunit.xml with version: 5.1.11
>>> _Shift_ 5.2 Event: matched core file: tests/TestCase.php with version: 5.1.33
>>> _Shift_ 5.2 Event: matched core file: database/migrations/2014_10_12_100000_create_password_resets_table.php with version: 5.1.33
>>> _Shift_ 5.2 Event: matched core file: public/.htaccess with version: 5.1.33
>>> _Shift_ 5.2 Event: matched core file: config/broadcasting.php with version: 5.1.11
>>> _Shift_ 5.2 Event: matched core file: config/cache.php with version: 5.1.33
>>> _Shift_ 5.2 Event: matched core file: config/compile.php with version: 5.1.33
>>> _Shift_ 5.2 Event: matched core file: config/database.php with version: 5.1.11
>>> _Shift_ 5.2 Event: matched core file: config/filesystems.php with version: 5.1.33
>>> _Shift_ 5.2 Event: matched core file: config/queue.php with version: 5.1.11
>>> _Shift_ 5.2 Event: matched core file: config/view.php with version: 5.1.33
>>> _Shift_ 5.2 Event: could not upgrade config files Data: {"1":"config\/auth.php","2":"config\/mail.php","3":"config\/services.php","4":"config\/session.php"}
>>> _Shift_ 5.2 Event: could not upgrade package.json
>>> _Shift_ 5.2 Event: app contained phpspec/phpspec requirement of ~2.1
>>> _Shift_ 5.2 Event: found customized namespace

*** _Shift_ ran in: 212.209509
复制代码

从这些日至里能够看到哪些文件被升级了，用到了哪些功能、哪些组件，等等。ios

(一)最流行的Laravel版本——5.3

不少apps停留在了5.3,可能由于PHP版本的要求，由于到了5.4测试想转换到Dusk，或者auth组件的变化等。laravel

这应该符合现实状况，由于laravel在5.2～5.3期间一方面作了不少变更，你们要逐步适应和学习，另外一方面这些人性化的变更也让laravel更加流行和易用，laravel被大批量地用于生产环境，同时这些变更自己，也逐渐使laravel趋于成熟，知足了你们实际项目的大部分须要。可能没有了特殊的功能须要，你们也就不会那么急迫地更新版本，自己laravel 5.4开始的更新变更也相对小了不少。git

固然，也能够说你们的项目还都在“升级的过程当中”，取决于升级的时间、人力成本等因素，若是能够的话，可能你们都还想升到laravel 5.5,也即第二个LTS版本。github

(二)最流行的第三方组件

须要注意的是，接下来的数据样本，laravel 5.5及以上版本的要小一些，同时laravel自身的核心组件，都被排除在外了。web

  • 58% of apps use guzzlehttp/guzzle
  • 36% of apps use predis/predis
  • 34% of apps use laravelcollective/html
  • 32% of apps use league/flysystem-aws-s3-v3
  • 27% of apps use intervention/image
  • 25% of apps use maatwebsite/excel
  • 24% of apps use spatie/laravel-backup
  • 23% of apps use laravel/horizon
  • 22% of apps use bugsnag/bugsnag-laravel
  • 21% of apps use laravel/socialite
  • 20% of apps use laravel/passport
  • 19% of apps use sentry/sentry-laravel
  • 15% of apps use spatie/laravel-permission
  • 14% of apps use laravel/scout
  • 14% of apps use league/csv

流行的开发辅助组件：redis

  • 35% of apps use barryvdh/laravel-debugbar
  • 28% of apps use barryvdh/laravel-ide-helper
  • 19% of apps use laravel/dusk
  • 11% of apps use laravel/browser-kit-testing

编者点评：sql

  • 值得一提的是，早在两年前（2016年），这里面的一些对于初学者来讲比较关键的第三方组件，在咱们的Laravel系列课程里也都带领你们使用过了，好比必备的表单组件laravelcollective/html，在咱们《Laravel实战：任务管理系统（一）》就跟你们见面了；
  • 处理图片必备的intervention/image，也在咱们《Laravel实战：任务管理系统（一）》中大量使用，后来出现了不少其余的图片相关组件，但每每背后也是基于的intervention/image，好比说近来流行的spatie/laravel-medialibrary；
  • 项目备份必备的spatie/laravel-backup，是咱们在《Laravel&Vue实战：任务管理系统二》一开始就使用的，当时该组件还名不见经传；
  • 关于权限，能够说一开始数一数二的是Zizaco/entrust,为此呢咱们还专门出了免费的公开课《Laravel Entrust角色权限管理》，可是呢entrust的做者忽然从去年开始不怎么活跃了，因而santigarcor/laratrust做为entrust的维护版本出现，已经安装了entrust的能够无缝迁移到laratrust上，固然这期间另外一个权限组件spatie/laravel-permission凭借其强大的活跃也流行起来了，Laravel也推出了自身的权限功能——Policy。因此权限这块，其实用哪一个功能就取决于你本身了，都不错，均可以，那么若是你权限这块感受有障碍，仍是推荐咱们的免费的公开课《Laravel Entrust角色权限管理》，了解了原理之后，你能够自行在santigarcor/laratrust或spatie/laravel-permission之间选择。
  • 搜索必备组件laravel/scout，这个背后的driver默认基于的是付费服务Algolia，在国内咱们更喜欢开源的Elasticsearch，laravel/scout与Elasticsearch搭配来开发实时搜索相关的功能，能够看咱们的《Laravel & Elastic全文搜索实战》课程。
  • 关于guzzlehttp/guzzle排第一位，多是由于这两年api开发开始流行，传统上咱们常常用guzzle来处理http请求，因为数据来源大部分都是5.3及如下的，这个时候passport与axios还刚开始流行，因此这一点上，可能后期咱们会看到passport的排名将攀升，axios由于是前端组件，可能就会被排除在统计数据以外了，可是咱们毫不能忽视它的日发流行。

（三）改动最多的文件——config

config文件是改动最多的，虽然这很合理，可是呢改动默认的config文件，也容易致使升级障碍。一般，你能够有其余的方式来处理这些改动，从而使config文件保持默认的样子。

这期间必定记得经过ENV环境变量来改动config文件的值。不少应用喜欢改变config文件当中的默认值，而不是设置ENV，好比假设config/mail.php:

'from' => [
    'address' => env('MAIL_FROM_ADDRESS', 'shift@laravelshift.com'),
    'name' => env('MAIL_FROM_NAME', 'Laravel _Shift_'),
],
复制代码

这样呢并很差，仍是得设置ENV，让config文件保持默认：

'from' => [
    'address' => env('MAIL_FROM_ADDRESS', 'hello@example.com'),
    'name' => env('MAIL_FROM_NAME', 'Example'),
],
复制代码

当你有不少的配置选项须要设置时，再一种方式就是建立你本身的config文件，好比建立config/system.php, config/settings.php，这样你就不用分别改动多个config文件了。

（四）不推荐自定义的全局namespace

使用默认的APP namespace就好。有9%的apps使用了自定义的namespace，而这个数值应该是0.

若是你更改过namespace，能够这样来改回：

artisan app:name App
复制代码

固然这并不能改回你在数据库当中，使用到多极对应关系（polymorphic relationships）时的记录，那个你得本身经过sql query来改变了。

编者按： 这个呢，其实在5.3及如下版本，若是经过artisan app:name改变了namespace，其实是会发生不少莫名bug的，因此不推荐出于好奇随便设置app:name，除非你知道本身在干什么。

（五）apps的目录结构

接下来是在app目录下发现的非laravel官方文件夹：

  • 36% of apps contain app/Models
  • 29% of apps contain app/Services
  • 29% of apps contain app/Helpers
  • 25% of apps contain app/Traits
  • 20% of apps contain app/Rules
  • 18% of apps contain app/Repositories
  • 17% of apps contain app/helpers.php

在laravel 4时代，是默认有app/Models文件夹的，到了5, laravel做者特地将其删掉，由于model这个词在不一样的人那里理解不同，有的人认为一个app的model是其整个的业务逻辑，有的人认为model是一些与关系型数据库进行交互的class，为了避免限制你们，干脆删掉，让开发者本身决定该怎么安置model，也即你能够本身建立app/Models文件夹，而后遵循MVC框架的传统方式，也能够“面向业务（service）”，搞一个DDD（Domain-Driven Design）。

固然，这里手动建立 app/Models的，通常都是model数量超过了10个。可是，这里咱们想更进一步地，若是model数量超过50个呢？这个时候仍是简单地放在 app/Models里，还有特别的意义吗？

app/Services文件夹通常放置一些独立的业务相关的逻辑，能够用来将你的某一部分业务逻辑独立出来，使业务逻辑模块化，甚至方便后期将其独立成为单独的package给其余的项目使用，或者成为一个microservice，关于面向service，或者说package开发，就须要你对laravel底层及其原理有足够的掌握了，这里就推荐咱们的《Laravel底层核心技术实战揭秘》

app/Helpers和app/helpers.php应该大同小异，前者放置一些辅助功能的class，后者放置一些全局的helper function，这个在咱们的《Laravel&Vue实战：任务管理系统二》中也给你们介绍过了。

app/Rules，这个文件夹严格来讲是laravel自己的，由于它是咱们执行artisan make:rule后产生的，关于laravel 5.5之后建立自定义的验证规则，也即rule，若是有不懂的同窗，能够看咱们以前给你们提供的文章：【Laravel 5.5新特性】更方便地建立自定义的数据验证规则 和 Laravel的unique和exists验证规则的优化

关于repository，是否放置在app/Repositories内不是关键，关键是你是否使用，Repository Design Pattern能够说是laravel自己以及其众多第三方组件的命脉之一，Repository Design Pattern对于你分离业务逻辑，或者开发package，也很是关键。repository在laravel刚出来的时候，曾经在国外社区盛极一时，可谓是学laravel必学的，大概在2014年左右能够说是成为一种规范和标准在推行，甚至官方很是简单的起步项目都要介绍和使用，可是呢国内laravel流行的较晚一些，等到国内开始追逐laravel的时候，国外社区都“懒得提”repository了，加上不少国内材料或教程有意无心地躲避repository，说太复杂了不适合新手，不必让新手学之类的。但其实不是，并不复杂，也并不须要向所谓的新手藏着掖着，不然新手怎么成为高手？

若是你对repository还感到陌生，不知道是咋回事，那么请务必看看咱们的《Laravel实战：任务管理系统（一）》,该课程可谓是国内惟一在初学阶段就让你轻松尝鲜Repository Design Pattern的，让你在初学阶段就打下往后成为高手的根基，固然若是你想真真正正掌握Repository Design Pattern的全貌，仍是推荐咱们的《Laravel底层核心技术实战揭秘》

（六）改造基本的继承关系

这个通常是指本身额外建立一个BaseController 或者 BaseModel class，让它们继承laravel默认的controller或model，而后本身的具体的controller或者model再继承这个BaseController 或者 BaseModel,这期间就能够在BaseController 或者 BaseModel里作一些本身的逻辑。

有23%的应用这么作了，这个呢其实也是不推荐的，这种作法每每在早期的一些国外教程或材料中能看到，可是新近的都不会这么搞，同时这个应该在国内不是很大的问题。

就好比说model，当咱们想扩展其功能的时候，更优雅的办法是使用trait，而不是写到BaseModel里，这符合咱们编程设计原则里常说的“composition over iinheritance”

（七）Facade的滥用

57%的应用滥用，或者说过分使用facade。Facade自己已然是laravel社区内一个极具争议的话题，或者说是laravel备受非议的一个话题，关于这一点，若是有不了解的，能够看看咱们以前给你们写的扩展文章PHP中的facade pattern（外观模式）。那么大部分的apps乱用facade，无异于火上浇油了。最大的争议发生在controller和middleware当中滥用Request和Auth

好比一块儿看一下这个controller逻辑：

public function store()
{
    $data = Request::only('product_id', 'token');

    if (Auth::check()) {
        $data['email'] = Auth::user()->email;
    }

    // ...
}
复制代码

这里呢使用Request来获取请求数据，使用Auth来获取当前用户。可是呢，不管是controller仍是middleware，均可以注入一个request实例：

public function store(Request $request)
{
    $data = $request->only('product_id', 'token');

    if ($request->user()) {
        $data['email'] = $request->user()->email;
    }

    // ...
}
复制代码

这样就不用调用两个facade，而只经过一个request object。关于方法注入、或者依赖注入、或者依赖解析等，不管是咱们的初级课程《Laravel实战：任务管理系统（一）》，仍是咱们的高级课程《Laravel底层核心技术实战揭秘》,都有大量的讲解和使用，这些也是掌握laravel、成为高手的关键。

固然，若是你有真正学习了咱们的《Laravel底层核心技术实战揭秘》,或者在阅读PHP中的facade pattern（外观模式）之余作足了功夫，那么你会明白，上面的代码也并不能彻底解决facade滥用的问题，由于毕竟Request自己也是一个facade，可是毕竟下降了问题的程度，从而在更好的程序设计和测试过程当中，能更大程度地解耦。

（八）View视图中的query查询

24%的应用在view中存在数据查询，这天然是bad practice，视图层不该该直接交互Model，确保使用Controller来传递相关的数据

（九）不要直接调用ENV变量值

42%的应用直接调用ENV变量。Laravel提供了artisan config:cache来提升性能，为了充分利用这一功能，不要直接调用env数据，而是在config文件中调用。所以，你必须得经过config来间接获取env数值

（十）CRUD型Controller

77%的应用尚未采用CRUD型Controller。所谓CRUD型Controller，指的是将controller里的方法限制为默认的CRUD这四类，或者说是默认的resourceful controller，也即里面只有index()、create()、store()、update()、edit()、show()、destroy()这七个方法，任何多出来的方法均可以重构到单独的一个controller，这符合坊间“全部的操做其实归根到底都是CRUD操做”的说法。

固然这一理念呢，还比较新颖，属因而2017年的laravel国际会议laracon上才开始推荐，因此大部分的应用尚未真正地实践，应该国内的开发者也大都对此陌生，不过没关系，在近期的课程更新中，咱们将会在《Laravel底层核心技术实战揭秘》中给你们介绍相似的一些流行作法。

（十一）Controller内的数据验证（Validation）

89%的应用在Controller内进行数据验证，这也是很差的实践——正如咱们在入门课程《Laravel实战：任务管理系统（一）》里就讲过的，Controller只是一个“指挥者”，它正常来讲不负责任何具体的逻辑，因此此处的数据验证，最好是放到单独的Request文件中，正如咱们在入门课程里提倡的那样。

（十二）Blade相关的命令

71%的应用尚未使用Laravel提供的一些blade命令。用的最少，但每每最有用的是@auth，@guest，@json，@method，@csrf。

固然，这一项所提到的blade命令，其实大都是laravel 5.5才新出的，甚至有些呢文档上也没有说起，因此你们可能还不熟悉。天然，咱们在blade里面可使用原生的PHP标签，可是那样就有可能没有充分利用起来laravel给咱们提供的便利与优雅，因此blade当中，咱们常常也提倡尽量地不用原生php标签。

关于blade命令，咱们以前也给你们写过两篇文章：【Laravel 5.5新特性】能够在blade中自定义if判断的简略标签 和 Laravel Blade中的@each用法

（十三）额外的一些数据分析

最后呢是一些附加的统计数据，注意的是，该项数据样本相对较小，并且只是限于laravel 5.5及更新版本，该项数据的生成使用的是stefanzweifel/laravel-stats这个组件。

+-------------------+-------+---------+---------------+------------+
| Name              | Usage | Classes | Methods/Class | LoC/Method |
+-------------------+-------+---------+---------------+------------+
| Commands          |   66% |    6.37 |          2.42 |       9.68 |
| Controllers       |   67% |   20.91 |          4.10 |       6.28 |
| Events            |   29% |    5.63 |          1.64 |       7.69 |
| Jobs              |   31% |    4.11 |          2.36 |      11.84 |
| Listeners         |   39% |    5.35 |          1.89 |       5.16 |
| Mails             |   39% |    6.72 |          2.06 |       6.71 |
| Middleware        |  100% |    4.22 |          0.12 |       4.93 |
| Models            |   99% |   17.80 |          3.75 |       3.79 |
| Notifications     |   39% |    4.57 |          3.80 |       3.71 |
| Policies          |   19% |    5.09 |          3.96 |       2.88 |
| Requests          |   58% |   11.04 |          2.07 |       2.52 |
| Resources         |    7% |   14.75 |          0.94 |       4.95 |
| Rules             |   17% |    2.40 |          3.07 |       2.86 |
| Service Providers |  100% |    6.28 |          1.97 |       4.61 |
| PHPUnit Tests     |  100% |    9.96 |          2.02 |       6.63 |
| Dusk Tests        |   18% |       5 |          3.00 |       6.67 |
| Browserkit Tests  |    3% |      13 |          4.16 |       6.05 |
+-------------------+-------+---------+---------------+------------+
| Total             |       |  144.54 |          2.18 |       5.72 |
+-------------------+-------+---------+---------------+------------+
复制代码
  • 相对来说，Jobs、Controller和Events中的每个method中包含了最多的代码
  • 虽然phpunit test显示的是100%的使用，但实际的状况是，大部分都只是laravel默认自带的示例测试文件。其余的数据显示，只有27%的应用里包含有自定义的测试
  • 多是laravel-stats这个组件自己的bug，由于显示的是67%的应用使用controller，实际上不可能这么低

结语

看了这些数据，你的laravel学对了吗？用对了吗？但愿这些数据能给你的laravel使用与学习，提供更好的参考与建议～

值得自豪的是，经过这些数据，能够看到两年前咱们pilishen.com出品的laravel从入门到高手系列课程，两年后的今天，依然能够说是始终保持在laravel规范使用的前列，所以凡是认真学习了咱们系列课程的小伙伴，应该也能够自豪地说本身的laravel用得很优雅、没问题，在此祝贺大家，同时感谢一往的支持。

这些数据，是过去的两三年内全球范围内Laravel使用状况的一个缩影，下一个时代，或者说下一个阶段，应该就是Laravel 5.5的时代了。值得庆祝的是，咱们的这些系列课程，将于近期通通升级重录，更新到laravel 5.5及更新的版本，以保证小伙伴们继续领先下一个时代，下一个将来的两三年。这次更新，将不仅是简单地版本更新，不是简单地把已有项目再作一遍，而是一次系统性的经典升华，升级后的课程将不只包含本文数据里提到的这些最佳实践与建议，并且将包含大量这些数据里都未曾提到的更优实践，以此来切实保证我们的小伙伴们真真正正地领先同行。并且，咱们已经上车的小伙伴们，将完彻底全免费得到更新后的全部课程，不止过去，包括未来，相信大家都是国内laravel开发者中的佼佼者～

到如今尚未上车的小伙伴，你在等什么呢？～

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程