/
来自实践的经验

如果我是David Grudl,我会改变Nette的做法

18. 11. 2022

Obsah článku

我已经积极使用Nette Framework近6年,用于商业软件开发。在最初的几年里,我非常热心,该框架完美地解决了我们作为一个团队的所有需求,基本上没有理由去寻找其他工具。

大约从2019年开始,我开始看到Nette内部原来的热情有所下降,我开始怀念一些高级功能。通常这些都是超出框架本身的东西,所以我甚至不指望它们会被实现,但另一方面,开发者必须做出决定,如何继续向前发展,也许会接触到不同的技术。

数据库层

我认为Nette数据库是该框架的最大错误之一,不幸的是。

每周我们都会在公司进行面试,刚从学校毕业的大三学生,甚至是从其他框架过渡的中间人,都会申请并发现Nette数据库,作为他们探索Nette的一部分。作为一个数据库层,它不是太糟糕,但问题是在实际项目中的实际使用。

这是因为Nette数据库没有努力推动开发者从一开始就使用严格的数据类型,为列和关系命名,将查询(存储)方法与模型分开,以及其他总体上有很大作用的细微差别。

多年来我一直使用Dibi库,它在当时发挥了巨大的作用。它允许你相当好地查询数据库,并统一了界面。另一方面,时代在进步,当数据库返回未定型的对象时,PHPStan只是在原则上不高兴。

就我个人而言,我将把对实体和资源库的本地支持纳入Nette数据库,或者在Nette中为Doctrine提供官方支持。如果你在大公司层面上对应用程序进行编程,你必须认真对待开发,特别是Doctrine有很大的意义。同时,你要马上对新人进行更好的技术教育,你不希望教他们老的习惯。

Tracy和错误记录

我仍然认为Tracy是PHP最好的运行时调试器。

2017年,当我来到一家不知名的数字机构,看到他们的Nette项目的技术状况时,我感到很震惊。有多少次,他们的网站是用纯PHP编写的,没有任何记录错误的尝试。一个相当简单的解决方案是在项目上安装Tracy,调用Debugger::enable(),然后不再做其他事情。这些bug被自动记录到一个目录中,只需要每隔几天手动拾取。

至于特蕾西,在我看来,它是一个成品,大卫没有什么理由去改进。另一方面,我仍然看到在新的方向上有改进的余地。

例如,为什么Tracy不包括为那些认真对待安全的公司或个人提供的付费功能?

Tracy可以实现一个自定义的Sentry类型的Web界面,在那里你可以创建一个账户,生产的Bug会自动通过API发送,你可以跨项目追踪它们。该应用程序还可以请求个别网站,并自动检测到它不可用,并以其他方式通知所有者(因为Tracy无法从逻辑上检测到服务器崩溃)。我有时也会遇到这样的问题:Tracy不小心在生产现场启用了,你可以通过DIC找到如何访问数据库或其他地方。特雷西也应该提醒你注意这一点。

Tracy还可以实现我在Node.js中知道的其他小东西。例如,对于源代码的显示,可以选择以特殊方式突出显示该行的字符间隔,为什么有可能突出显示一行中的特定标记。同时,最好能增加对第二条(也许是蓝色)高亮线的支持,以显示应用程序的下一部分的上下文。

当显示一个源代码片段时,我不会害怕添加一个按钮,可以在ajax中渲染代码的其余部分,这样我就可以在浏览器中直接从调用栈中探索它。这就是Symfony所做的,而且是一个伟大的功能。如果再辅以基本的静态分析,具备抓取方法、类和继承的能力,就可以为整个团队节省大量的调试工作。

如果callstack正在遍历一个包,那么最好能显示我为某个特定文件工作的包的版本。我经常会在正在开发的软件包中抛出一个错误,我可能会在视觉上知道它是一个旧版本。

静态路由

在Nette Router中,我将允许定义一个新的类型,称为静态路由器。它将是基本路由器的后代,但它只能接受string-literal,这不是一个正则表达式,而是一个直线路径。很多页面都是静态工作的(联系人、各种文章,甚至令人惊讶的是经常是主页),由于这个原因,路由器每次都要评估regex规则进行匹配和URL组成。

例如,如果在Latte模板中使用静态路由,它可以在模板编译时安全地翻译成静态的https://zh.php.brj.cz/path字符串,因此不需要在每次请求时编译布局中的100个URL,例如,。

我知道我可以通过模板方面的缓存实现同样的功能,但我更希望得到一个系统的解决方案。

在Next.js框架中,我完全陷入了静态路由的概念。没有n:href这种东西,总之你必须事先知道URL,这就迫使你不要做那么多重定向,事先考虑URL格式,并保持它们的持久性。

PSR接口

我觉得Nette没有原生地实现PSR接口是很遗憾的。作为一个包的开发者,如果你想在Nette上定义一个Composer的依赖关系,这就把你引入了歧途。一方面,Nette为你解决了很多问题,另一方面,你知道你以后根本不会更换它。不止一次,我发现自己更愿意使用Symfony、Laravel或完全不同的通用接口,因为缺乏一个通用接口。

缺乏对未来可移植性的通用标准的支持是我在2022年完全离开Nette的主要原因,我们在团队中完全用通用标准开发新的应用程序。

API层

如果你想用Nette作为后端来处理REST API请求怎么办?你是否建立一个presenter并以$this->sendJson()的方式发送响应?你会安装一个第三方库吗?或者你是大卫-格鲁德(David Grudl),他通过立即编写一个新的库来解决缺失的需求?

为什么Nette不能实现像REST API这样常见的开箱即用的东西?今天,几乎每个应用程序都需要通过API进行通信--例如,向前端提供数据。

对于新人来说,这再次导致他们使用内置的Latte和片段,而不是发现有一个更好的选择,那就是在旁边单独建立整个前端,只需向其提供数据。

相信10年后会发生什么

最后一点是非常务实的,来自于我们在团队中时常听到的业务部门的辩论。

如果David Grudl完全停止开发Nette,会发生什么?如果有人停止开发呢?我们会换成什么呢?那会有多大的挑战呢?

许多开发人员(通常没有企业经验)喜欢嘲笑这种担忧,说这没关系。比如说是的,但它不是。

当你在为是否在Nette或React和Node.js上投入时间来培训公司的初级开发人员而苦恼时,不幸的是,后者的选择胜出。

内特还没有错过这趟列车,但在过去六个月的几十次采访中,我的感受相当强烈。

Jan Barášek   Více o autorovi

Autor článku pracuje jako seniorní vývojář a software architekt v Praze. Navrhuje a spravuje velké webové aplikace, které znáte a používáte. Od roku 2009 nabral bohaté zkušenosti, které tímto webem předává dál.

Rád vám pomůžu:

Související články

1.
9.