验证应该在哪里，在 MVC 层还是在业务引擎？

Question

在 Spring 中编码的 Web 应用程序后端对执行密集计算的 "business engine" 进行远程过程调用。

这些密集计算具有高错误率，主要是因为从后端到引擎的错误请求and/or bad/insufficient 数据库中的数据。

因此，有必要向用户提供可以转换为消息的错误代码，以帮助识别问题。

     ----------         -----------          ----------
    |          |       |           |        |          |
    |   USER   | ----> |  BACKEND  | -RPC-> |  ENGINE  |
    |          |       |           |        |          |
     ----------         -----------          ----------
                             |                    |
                             |                    |
                           -----                -----
                   Config |     |     Business |     |
                   DB     |     |     DB       |     |
                           -----                -----

我认为应该在调用引擎之前进行验证，以便快速失败并避免等待响应后不可避免地会失败发送，根据负载排队，处理并return发送到后端。

问题：验证应该发生在：A) 后端还是 B) 业务引擎？

奖金问题：如果答案是 B)，业务引擎是否应该 return 错误代码并让后端处理转换，或者同时实现 i18n的消息？

附加信息：

验证逻辑不是秘密，后端和业务引擎都知道。
用于通过RPC调用引擎的配置数据由后端拥有和存储（引擎除了请求之外没有其他访问权限）。
错误的 i18n 是必需的。

意见and/or备选方案for/against欢迎任何方法。谢谢。

Answer 1

在我看来，我不希望我的引擎对错误的请求执行计算。我认为这没有任何价值。因此，您的验证应该始终在您的后端执行，然后只应将过滤后的请求发送到您的引擎。您还必须改进您的 Web 应用程序，这样您从 UI 收到的错误请求的数量也应该减少。因此，在 UI 控制器本身中设置尽可能多的逻辑，以便以更好的方式过滤进入后端的请求。

Answer 2

should the validation occur in: A) the backend or B) the business engine?

是的。

在多个地方进行验证。在客户端上验证以获得快速反馈。在您的控制器中验证安全性，在您的存储库中验证数据完整性。您了解 JSR 验证组，对吗？

should the business engine return the error code and let the backend handle the conversion, or also implement the i18n of the messages?

坚持使用 JSR 验证开始。这个很不错。当出现验证错误时，它会抛出异常。将错误消息保存在属性文件中。

验证应该在哪里，在 MVC 层还是在业务引擎？

Where should the validation be, in the MVC layer or in the business engine?

spring

validation

spring-mvc

design-patterns

rpc