2019年 Laravel vs Yii

https://static.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更改时都定义单独的版本。

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

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