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

我已经积极使用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上投入时间来培训公司的初级开发人员而苦恼时，不幸的是，后者的选择胜出。

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