飞哥专栏
文章 技术 工程效率 项目管理 生活 看法 关于
飞哥专栏

2019年 Laravel vs Yii

 
       

https://www.ffeeii.com/ffeeii.com/2019/10/yii_vs_laravel.jpg

此文是一遍PHP目前最流行的2大框架，Laravel和Yii的对比，本文不进行Hello Word的性能对比，而是从其他方面进行详细的对比，这是任何项目架构前的思考，包含相关框架不同的演进，以帮助您决定选择哪个框架。原文链接 https://forum.yiiframework.com/t/yii-vs-laravel-a-2019-comparison/126646 欢迎大家对错误之处纠正。

一个热门话题是，每当需要启动一个新技术项目时，您都要花很多时间技术选型，比较，搜索，证明和测试要使用的技术堆栈，框架。

一般而言，影响您选择任何技术堆栈的决定的主要因素取决于：

  • 项目规模（小型，中型，企业）。
  • 项目的类型（OGC内容，电子商务，博客等）。
  • 给出的时间框架仅仅是一个POC，还是将在其之上实施的核心/基础。
  • 团队规模，技能，学习新事物的能力。
  • 技术社区的规模，支持以及发布的频率，开发路线图等。

考虑到以上因素，将在选择哪种技术栈，架构方面起很大的作用。

为什么对比？

在开始今天的文章（Yii2与Laravel的2019年比较）之前，我一直很犹豫，在过去的两年中，我们进行了大量的战斗，文章和讨论，并且一直在继续。公平地说，这些讨论是健康的，并提供了不断增长的巨大知识共享部分。

当我开始这篇文章时，我决定以一种不同的方式来使用它，而不是只为Yii vs Laravel的功能提供一个比较表，然后尝试从另一个角度，从一个工作/交易的人那里来讨论它。从2011年至今一直使用Yii框架，直到今天为止，并且已经实现了系统的庞大部分，这些系统每天要为其一个API处理8千万+个请求。具有很高的可用性/容错能力，并且在开发的每个步骤中都考虑了性能。

最后，我撰写了一篇长篇文章，因为我需要分享实践经验中的比较结果，并且公平地讲，我必须涵盖两个框架中的大部分内容，以帮助您决定选择哪个框架。因此，本次讨论将分为三个主要部分，在每个部分中，我将重点讨论一个主题，并且在本文结尾处，将对优点/缺点进行简单的比较，希望可以帮助您确定选择哪一个。

第1部分
不只是一个框架！

为了澄清问题，要拥有一个高可用性的容错系统，它不仅取决于您使用哪种框架/编程语言，而且从体系结构角度，弹性和基础结构方面起着很多因素的作用。因此，您无法判断出Yii2 / Laravel仅会为您提供高可用性系统，因为有很多因素会影响到它。

如上所述，在使用Yii / Yii2进行了8年以上的持续开发之后，我将在第1部分和第2部分中与您分享有关它的笔记，然后在最后一部分中，我将与您分享我对Laravel的体验以及如何使用它与Yii相比。

为什么选择Yii 1？

当我从Zend / CodeIgniter的背景开始于2011年开始使用Yii时，我当时的问题是：

  • 什么是Yii？快速，安全，高效，灵活，可扩展的MVC框架。

  • 它指的是什么？是的。

  • 我为什么要去呢？

  • 与当时的Zend相比，包装尺寸较小。

  • MVC支持。

  • 许多扩展将促进您的入门过程。

  • 互动性强，支持性强的社区，不会让问题无答案。

我为什么要从Zend转到Yii？当时的Zend是最常用的框架，而开发PHP的同一家公司则开发Zend。但是，框架的规模更大，必须编写大量的代码才能实现一个简单的CRUD系统，并且花费了较长的开发时间，所有这些因素在尝试可以简化您工作的新事物中发挥了重要作用。

还有很多其他问题，例如如何以及如何以及如何？老实说，我从Zend迁移到Yii花费了更长的时间，这归结为许多因素，因为我仍处于起步阶段，并以Zend的思维方式思考如何做事，除了没有真正的生意可以在独立项目中实现的案例。

由于上述原因，Yii 1入门使我花了大约3个月的时间。然后，我搬到了另一家公司，他们开始使用Yii框架对其网站进行新的改造，在其中我发挥了重要作用，实现了系统的大部分，并与MVC中的框架中的每个组件进行了交互。缓存层，资产管理，安全的API，安全性和许多组件/扩展。

老实说，文档，社区和教程为我们提供了很多帮助，帮助他们按照最佳实践快速完成工作。但是，在此期间，我们遵循了敏捷的开发策略，在2013/2014年，我们在不同的方面遇到了问题，例如：

Yii 1问题

  • Yii如何管理数据库连接，例如我们需要拆分读/写操作，那时框架本身不支持此操作，并且我们被强制扩展CDbConnection类并在执行之前中断查询，以便将读查询拆分为连接并将查询写至另一个连接（主/从架构）。
  • Yii如何管理资产，因为我们希望通过CDN提供资产，因此需要一种方法来合并资产并将其以方便的方式上传到CDN，以避免延迟和重复操作。
  • 对于宁静的API，没有明确的方法来处理API版本，如何进行速率限制，而这要求我们实施自己的方法。
  • 在这段时间里，PHP作为一种语言也在发展，并且即将发生重大变化，例如名称空间，特征，Yii 1无法100％适应的类型。
  • 每当您需要使用扩展程序时，都必须下载，解压缩并将其复制到您的项目中，当时Yii 1中并不常用composer。

**第2部分
** 2014年末，Yii推出了其第二版框架（Yii2），该框架与Yii1并不向后兼容，并迫使我们花一些时间阅读和理解Yii提出的新变化，以开始计划新的版本。修改/重写过程。

不仅是框架，还有新语言支持！

好消息是，PHP还对类自动加载和名称间隔进行了重大更改，这鼓励我们加快向Yii2的迁移。

Composer

Yii2的默认安装是通过composer进行的，这是Yii1的第一个重大更改，以限制开发人员开始使用composer并熟悉如何在Yii中进行调整。 Yii2提出了两种不同的框架：一种用于与Yii1框架非常相似的基本项目，另一种是用于引入多个应用程序框架的高级模板，更多详细信息请参见 https://www.yiiframework.com/extension/yiisoft/yii2-app-advanced/doc/guide/2.0/en/start-comparison

我们的用例更适合高级模板，该模板中有多个应用程序（通用，控制台，后端，前端，api）。可以在这里找到更多详细信息 https://www.yiiframework.com/extension/yiisoft/yii2-app-advanced/doc/guide/2.0/en/structure-directories

Yii 1问题已在Yii 2中解决

Yii2提出了针对Yii1开发人员面临的所有主要问题的解决方案，例如资产管理，数据库读/写连接，通过composer进行的扩展以及在Restful方面的巨大努力，这使您充满信心，无论您使用哪种用例都能适应它在Yii2中（是，是），例如（版本/身份验证/速率限制/响应格式…等）以非常方便和智能的方式进行介绍。

与jQuery / Bootstrap无缝集成，带来什么缺点？

在前端方面，Yii2在提供用于操纵数据，如何表示数据以及无缝集成的小部件方面付出了巨大的努力。 Yii团队做出了一个好坏决定，因为该框架与jQuery / Bootstrap堆栈紧密耦合，并使得前端很难将Yii2与其他前端框架（如React / Angular / Vue…等）一起使用。

这是他们开始认真计划Yii 3的主要原因之一，因为Yii 3已从jQuery / Bootstrap堆栈中分离出来，并完全专注于后端。但是，对于仍然喜欢jQuery / Bootstrap的人，他们仍然可以肯定使用它，但是默认情况下未启用它。

RESTful 支持

回到Yii2框架的RESTful支持，进一步提到的Yii2在路由，响应格式，身份验证，速率限制，版本控制和错误处理方面提出了一套完整的解决方案。我将在这里进一步扩展，因为这是我一直致力于处理的主要领域之一，并且实施了每天处理8000万个以上请求的解决方案，在我们的情况下，我们将使用多个客户端（Android应用程序，iOS应用程序，PWA）不同的应用版本和不同的功能/行为。

深入了解有关以下方面的RESTful支持：

  • 路由，Yii2具有类yii \ rest \ UrlRule

默认情况下，它将创建一整套子URL规则以支持基于动词（GET，POST，PUT，DELETE和HEAD）的路由，并将其路由到适当的操作以处理请求。

  • 响应格式，Yii2具有yii \ filters \ ContentNegotiator过滤器，该过滤器足够聪明，可以理解客户端接受的响应格式并以所需格式返回响应，例如JSON / XML / HTML / Text…等。以及具有哪些属性/实体，字段和扩展查询参数为如何扩展当前资源而无需重复工作/代码提供了非常有用的方法。
  • 身份验证，Yii2具有身份验证器行为，可与HTTP Basic Auth，Bearer Auth，Query Param Auth…等不同的身份验证方法配合使用。可以将其配置为无缝验证请求并继续/拒绝请求。
  • 速率限制，Yii2具有yii \ filters \ RateLimitInterface，负责防止API滥用和从同一用户发送太多请求。
  • 版本控制，这实际上是很多辩论，观点，缺点，优点的主题之一，每个人的用例都各不相同。但是，Yii2提供了一种解决方案，可确保以健壮的方式同时向后兼容和持续集成。
  • 错误处理，Yii2遵循HTTP标准代码来处理不同的错误，这使客户端更容易预测正在发生的错误并相应地进行操作，例如未经授权/内部服务器错误/未找到/验证错误是RESTful世界中使用最多的错误。

总结Yii 2

话虽这么说，作为一个框架，Yii2确实做得很好，并且适合所有Web开发功能。而且，它与其他组件和服务集成，例如数据库SQL / NoSQL，缓存Redis / Memcached，身份验证，响应格式，简单格式，单元测试等。

新兴架构，不同需求

鉴于Yii2于2014年末推出，而我们现在已经到2019年，已经发生了许多变更/堆栈/技术，除了微服务/的发展之外，还出现了各种机制，软件架构。纳米服务架构，无服务器架构，移动优先产品和渐进式Web应用程序。然后，为了实现独立集成/部署的简单/独立服务，对微型框架的需求就增加了。因此，不再建议将大型系统实现为单个/复杂单元。

Yii 3？

Yii团队将这些更改/因素考虑在内，并开始研究Yii的第3版，该版本仍处于起草阶段，尚无发布日期，尚可在https链接上找到更多详细信息： https//www.yiiframework.com/wiki/2547/draft-understanding-yii-3 20

考虑到这一点，如果您要基于Yii2开始一个新项目，则应密切注意Yii3的草稿，以确保您/将不使用已弃用的功能，这将使您更加头疼您是一名软件架构师，请确保在升级到Yii3时不会发生重大变化。

第三部分
Laravel

我将讨论Laravel，以及我的经验，优点，缺点和关注点。但是，值得一提的是，我仍然是Laravel的初学者，无法深入研究所有组件，它的工作方式和主要用例，但是我将尽力提供高层次的分析，并将继续讨论。让您也能听到您的声音。

Laravel框架

Laravel在他们的网站上说他们是一个Web工匠的PHP框架。它可以通过composer安装，并提供一个目录结构，包括（应用程序，引导程序，配置，数据库，公共，资源，路由，存储，测试，供应商），更多详细信息可以在此处找到https://laravel.com/docs /5.8/结构4

我最关心的这个结构是MVC在哪里？并且已经在链接 https://laravel.com/docs/5.8/structure 4上被他们质疑/回答了

模型目录在哪里？

当开始使用Laravel时，许多开发人员由于缺少models目录而感到困惑。但是，缺少这样的目录是有意的。我们发现“模型”一词含糊不清，因为它对许多不同的人意味着许多不同的事物。一些开发人员将应用程序的“模型”称为其所有业务逻辑的总和，而其他开发人员将“模型”称为与关系数据库进行交互的类。

因此，我们选择默认情况下将Eloquent模型放置在应用程序目录中，并允许开发人员将其选择放置在其他位置。

在我看来，对于基于MVC的框架，它会明确定义其MVC结构，而不是让开发人员根据他们的需求进行定义。由于您无法实施工具，因此要求该工具的用户使用它，但是他们希望至少没有默认设置开始。

与项目框架有关的另一个问题是，应用目录包含（广播，控制台，事件，异常，Http，作业，侦听器，邮件，通知，策略，提供程序，规则），而控制器又在哪里？它默认情况下不存在，并且说实话，以上结构无法帮助您预测其工作方式，而无需深入研究他们的文档来了解它。这里不遵循配置约定，因此您必须付出一些努力来了解这些组件/目录以及如何处理。

与上述结构有关的另一个问题是，我看不到上述目录之间有任何关系，因此无法将它们全部放在同一伞下；如果我想将其与Yii2结构进行比较，则Yii2具有适当的结构，因为每个应用默认情况下都包含（model，视图，控制器，组件，配置，Web，资产，运行时，测试），您可以在其中明确知道代码应在何处进行。

Laravel文档

加快框架入门速度的主要因素之一是提供指南教程，其中提供了使用案例并提供了使用该框架实施示例的示例。在Yii中，您将获得指南教程，该指南向您提供了主要功能及其使用方式的浏览，而对于Laravel，他们的文档缺少此重要功能，它为您提供了常规设计模式的示例代码段，以及它们如何在Laravel中应用，例如facades，依赖注入，容器和服务提供。

拥有这样的指南将帮助任何高级开发人员快速入门，而不会花费太多时间来执行例行或小任务。

Laravel Contracts

Laravel提出的主要架构概念之一是Contracts，基于Contracts的定义，合同定义了框架提供的核心服务的一组接口，有关更多详细信息，请参见  https://laravel.com/docs/5.8/contracts

Laravel Contracts vs Yii2组件

Laravel中的合同非常有用，并且可以为您的代码提供某种抽象，但是，每当您需要使用合同时，都必须在类的构造函数/设置方法中要求使用合同。例如如果要使用缓存协定，则需要在类构造函数中明确要求提供它。另一方面，在Yii中，它们提供了基于组件的体系结构，并且组件是应用程序实例的一部分，可以通过配置加载，因此您可以像Yii :: $ app-> componentName一样通过调用任何组件来使用它。

在Yii组件中通常基于接口，例如Cache组件是一个具有以下主要方法（获取，设置，拥有，删除）的接口，并且任何缓存类（如Memcached / Redis）都实现了Cache接口，这是一种便捷的OOP标准，因此当您需要从Memcached更改为Redis时，无需更改任何代码/逻辑即可从配置更改它的问题。但是，在Laravel中，应在每个类中使用它显式提供合同，如果在多个类中使用相同的组件/服务，则这会增加开销，并且会导致代码重复。

Laravel路由

Yii中的路由是一个配置数组的问题，它由一个key => value结构组成，其中key是要匹配的模式，而value是要运行的目标控制器/动作。简单，方便和直接的样式。 Yii还提供了默认的路由技术，可以通过控制器/动作模式访问任何控制器的动作，因此您无需在路由数组中写入每个动作。另一方面，对于Laravel，您必须将路由编写为函数调用样式，这会导致编写过多的代码，并且控制器中的每个动作都应在routes.php中定义，以便能够公开它。

在Laravel中，有一种方便的方法来定义仅渲染视图的路由，因此，当您要定义不包含任何逻辑的仅视图操作时，可以节省大量代码。另一方面，在Yii中，您无法直接将路线映射到视图。

Laravel认证

Laravel中的身份验证提供了用于注册/登录/忘记密码/和重置密码的内置实现。 Yii中也提供了同样的功能，在大多数情况下，您无需覆盖其逻辑。

应该在路由配置文件中定义Laravel中的安全路由，方法是在路由定义之后立即调用中间件Auth，有关更多详细信息，请参见https://laravel.com/docs/5.8/authentication另一种在控制器的__construct中定义经过身份验证的路由的技术（） 方法。对我而言，我不喜欢这种方法，因为构造控制器是一项框架工作，任何定制都应在单独的步骤中进行，而不应在构造阶段中进行。

但是，在Yii中，可以在控制器本身的身份验证者行为中定义经过身份验证的路由，您可以在其中定义哪些操作是公共的，哪些操作需要经过身份验证的用户，并且可以在简单的配置数组中定义。

我已经处理过Yii和Laravel身份验证机制，并且发现两者都可以通过简单的方式完成，但是这取决于口味和喜好，对我来说，我可能更喜欢Yii的方式，而其他人可能更喜欢Laravel的方式。在所有情况下，这项工作都应该简单，可靠，因为它几乎在整个应用程序中都已使用，并且易于维护。

Laravel Façade

在Laravel旅途中，我注意到的主要内容之一是大量使用了Façade设计模式。这为您提供了很多魔术，并极大地丰富了您的课程。但是，这种魔术并不适合IDE使用，因此很难调试应用程序的工作方式以及这些方法的发生方式。另一方面，Yii完全兼容IDE，这可以极大地缩短开发时间，因为您可以自动完成并自动导入缺少的类等。

另一个担心是，Laravel大量使用了jQuery样式之类的闭包/回调函数，但是，这打开了函数式编程/ OOP的讨论，但这不会导致赢家。但是为了帮助您判断，您必须阅读功能和面向对象编程的优缺点，以了解这种方法的副作用。

Laravel视图

关于视图渲染，我不会深入研究Yii / Laravel，因为如前所述，随着PWA的发展，大多数Web应用程序现在都在客户端渲染，而不是使用服务器端渲染。有多个框架可用于此目的，例如React / Angular / Vue等。但是，值得一提的是，这两个框架都支持模板，如Laravel中的Blade和Yii中的Twig / Smarty。如果您需要深入研究，可以参考https://laravel.com/docs/5.8/views 1和https://www.yiiframework.com/doc/guide/2.0/en/structure-views

验证

Yii中的验证发生在模型中，您可以在其中定义一组规则，一组针对特定场景的规则，并定义每个场景要验证的属性，并且这非常干净/可靠地进行。

另一方面，在Laravel中，验证发生在控制器中，并且可以在定义所有验证逻辑的单独的类/ facade中编写。对于大多数验证案例，这两种解决方案都可以使用，但是，当您具有验证方案时，在Laravel中，您将遇到大量难以跟踪和调试的行。

Laravel / Yii中的ORM

Yii和Laravel中的关系数据在如何定义和调用方面都非常相似。 Yii2使用ActiveRecord，而Laravel使用Eloquent，它们都很方便，并且可以为您提供所需的控制权，公平的说，如果您对如何做某事有任何疑问，两个文档都可以为您提供很多帮助。

**总结
** 综上所述，Yii和Laravel两种框架都可以为您提供一天结束时想要实现的目标，这是编写代码的不同流派/不同口味。就健壮和精心设计的体系结构而言，这两个框架均受其背后的团队的良好支持。

如前所述，随着新兴的微服务/纳米服务体系结构以及对具有独立维护/部署的小型服务的需求，因此不再建议需要做很多事情的大型框架。由于大多数服务都专注于特定的操作/功能，因此可能不会使用框架功能的大部分。但是，常见的功能（例如请求/响应处理，路由，身份验证，授权，数据输入/输出操作）是常见的任务，您将在每项服务中使用它。

Yii正在开发该框架的第三个版本，该版本不推荐使用某些功能，而更改中断的功能也很重要，到目前为止，大部分内容都将保持不变。如果您要选择Yii2作为框架，则必须考虑这些因素。

Yii是一个IDE友好的框架，您可以大大延长开发时间，而Laravel则不是。但是，Laravel的语法很简单，您很快就会熟悉它。

考虑一下诸如React / Angular / Vue之类的客户端渲染框架，并考虑如何将其与这两个框架集成在一起，以及哪种方式才是您的最佳选择。

根据我的经验，Yii中的RESTful支持非常成熟和强大，Yii2 Serializer使您的资源可扩展到最大，而无需在每次api更改时都定义单独的版本。

最后一点，您选择的框架越能帮助您加快开发流程，并无缝地执行日常任务，其文档越能帮助您实现所需的目标，那么您的选择就很可能是正确且稳健的。

从一开始就明确说这两个框架都没有赢家，但是帮助大家对它们有更好的了解，可以帮助您方便地进行选择。

 Laravel, yii
 |