问题是：您是把业务逻辑放在对话框中，还是让它们尽可能简单？
我在 Blazor 上做 SPA。您需要更改授权用户的密码。有一个带有图标的文本字段，单击时会打开一个对话框，您需要在其中输入当前密码和两次新密码。验证成功后，通过 authStateProvider 服务向服务器发送请求（通过 DI 接收）。作为响应，我们收到来自服务器的错误或成功的密码更改。目前，一切都按上述方式进行，但我怀疑对话框应该只是没有任何容器、服务等的愚蠢形式。他们的任务是编辑数据/返回是/否（确认某事时）。
如果您删除对话框中的所有“多余”（服务、发送请求等），并且仅在保存时将成功结果返回给调用表单，那么您将不得不进行无休止的尝试以将密码保存在其中（在表单）（如果用户犯了错误，例如，密码复杂性较弱）。而且由于我们希望在对话框关闭后服务器会做出响应，因此用户会看到不断打开/关闭对话框（正在处理请求并且某些状态如下所示）=> UX 恶化，但在我看来那里没有 SOLID 违规。相反，在第一种情况下，我们违反了 SOLID，但用户很满意。
业务逻辑需要在服务器上完成。
如果可以提高用户使用应用程序的体验，则可以在演示文稿中复制部分业务逻辑。
重复 - 是的，这违反了 SRP（而不是整个 SOLID），但由您决定 - 您是为用户执行应用程序，还是遵守原则。