redux - ngrx(redux 模式)中的一些东西，我仍然无法用于大型应用程序

Question

我已经构建数据驱动的应用程序大约 18 年了，在过去的两年里，我已经成功地将 Angular 用于我的大型表单/基于 crud 的应用程序。你知道，经典的 sql server 数据库有数百个表和数百万条记录。到现在为止还挺好。

现在我正在移植/重新设计一个包含大约 50 个表单的桌面应用程序，所有表单都很复杂，功能齐全，“智能”。在过去的几年里，我的方法是简单地与后端 rest API 紧密合作，以根据需要检索、插入或更新数据，一切正常。

然后我偶然发现了ngrx，我确切地了解它是如何工作的，它做了什么以及为什么它对“响应式(Reactive)”应用程序有好处。

我的问题如下:在我提到的那种系统的通常生命周期中，您总是必须处理新数据，并且总是必须将所有内容告诉服务器。由于事务系统依赖于集中式数据交互，因此此类应用程序中几乎没有数据可以安全地“存储”在本地。没有“嘿，让这个员工的销售留在这里以备后用”之类的东西。

那么，当我的大部分数据都不稳定时，为什么管理本地“存储”如此重要呢？我明白为什么它对全局应用程序数据(如用户配置文件或一般 ui 相关状态)有用，但对核心数据本身有用？我不明白。您查询数据，将该数据插入表单，由用户处理并发送回服务器。不再需要该数据，如果您确实需要它，则再次请求它，因为自您上次与之交互以来它可能已更改其状态。

如果该州如此不稳定，我不明白我必须竭尽全力维护本地商店和所有样板。

他们说更改检测无法扩展，但我已经使用简单的“http 服务”模式构建了一些非常大的 Web 应用程序，它工作得很好，因为当你转到应用程序的其他地方时，大部分组件树都会被破坏，并且任何以前的订阅都变得毫无用处。即使是大而笨重的表格，表格的内部运作也从来没有那么大的问题，因为它需要来自商店的外部“帮助”。在我看来，一种形式的“状态”仅是在那一刻的那种形式的关注。是保持组件树同步吗？以前从未遇到过问题......即使对于具有大量共享数据的复杂树，如果所有数据都在那里，主细节最终也是一种平面模式。

对于其他组件，例如网格、图表、报告等，同样适用。他们得到了他们需要的数据，然后“puf”消失了。

所以现在你看到了我的心态。我正在尝试将其更改为更好的东西。为什么我错过了 redux 模式？

Answer 1

我在这里有一点经验!这都是主观的，所以我所做的可能不适合你。我的系统是一个复杂的系统，听起来和你的规模相似。起初，我与“为什么要在前端和后端构建复杂的逻辑”和“为什么要麻烦保持状态”等相同的问题作斗争。

redux/NGRX 方法对我有用，因为可以通过多种方式更改数据 - 也许是单个用户使用前端，也许是另一个用户进行更改，我想立即响应该更改以避免并发问题轨道。也许我的前端中有多个部分可以操作相同的数据。

在后端，我使用 CQRS 模式而不是传统的 REST API。通常，有人可能会建议重新实现命令/查询以“减少”对状态的更改，但是我选择了另一种方法。我不只是想将一个大对象图发送回服务器并让它盲目插入，我不想在客户端和服务器上重新实现逻辑。

我的基本“用例”生命周期看起来有点像:

加载数据列表(大小有限，并非所有属性)。

用户从列表中选择项目

客户端从服务器请求“完整”对象/ View /dto

客户端将响应存储在对象实体状态

用户开始修改数据

这些更改存储为状态不同部分的“进行中”更改。系统现在正在响应“进行中”部分中的数据

如果另一个更改来自服务器，它不会覆盖“进行中”的数据，但会替换对象实体状态中的内容。

如果需要，UI 会显示基础数据已更改/与用户输入的内容不同/其他。

用户单击“执行操作”按钮，或以其他方式触发要发送到服务器的命令

服务器执行命令。返回任何错误，或成功

服务器通知客户端更改成功，客户端清除“进行中”信息

服务器通知客户端实体 X 已更新，客户端重新请求实体 X 并将其置于对象实体状态。此通知将发送给所有连接的客户端，因此它们都可以正常运行。