Question

流行的Flutter Fluro package允许开发人员通过路由字符串在Flutter页面之间传递参数。例如：

collection/289/item/1224?view=grid

人们为什么要这样做？与通过对象传递参数相比，这种方法有很多缺点：

对于所有最终不是字符串的参数，您将失去编译时类型强制。您必须在某个地方打字。
您必须按ID引用对象并按ID查找它们，而不是直接获取对象。您必须为原本不会拥有的对象管理唯一的ID，并且可能还需要缓存远程加载的对象，以使它们不会在页面更改时重新加载。

我可以想到通过路由传递所有参数的以下可能的优点：

如果Flutter最终支持Android在后台杀死并重新启动应用程序的功能，则仅通过知道路由即可在同一页面上重新启动该应用程序。 Flutter小组可能会决定为此目的使用该路线。
如果您打算在应用的移动版本和网络版本之间共享代码，则可以通过使每个移动页面都变为无状态来实现此目的。

这些优势今天都没有实现。 Flutter团队尚未决定如何重新启动Android应用程序（据我所知），Flutter Web仍然存在漏洞和生产速度缓慢。

那为什么人们实际上通过路线传递论点呢？人们为什么使用像Fluro这样的软件包？仅仅是为了潜在的未来利益，还是他们现在正在实现利益？

（我正在计划如何构造自己的应用程序。）

Answer 1

Fluro优先考虑深层链接，当您的Web应用程序具有可以在Flutter中复制的一组路由时，就可以充分实现此优势。然后，如果有人安装了该应用程序，但通过手机访问了该网站，则可以将其无缝转发到该应用程序。

此外，在大型应用中，简单的route参数会迫使您使用高性能的存储库模式，因此您不必依赖于围绕路由传递模型。通常，这是编写应用程序的更好方法，因此它具有强制实施现代高性能架构的附带好处。

也就是说，就像任何技术决策一样，它也有其优点和缺点。如果您的特定用例与Fluro不匹配，则不一定是Fluro不好，而是您的需求与它不匹配。

我还没有研究的另一个软件包是auto_route，我怀疑它会有益于那些决定不使用fluro的项目

Answer 2

我认为这个问题很大程度上遗漏了路由方程式的很大一部分，即深层链接。

当您在内部和应用（内部导航）之间进行路由时，在周围传递对象绝对是有意义的。 Fluro的下一版本将支持此方法。

但是，如果您要与外部源（如Web链接，URL方案等）进行交互，那么有时不希望或不愿意构造一个对象。 API通常包含指向资源（例如{https://my.api/products/55）的URL。

对于这种情况，使用通配符或命名参数匹配非常有用。