应该在真正的基于企业Java的应用程序中进行层验证？

Question

我在少数企业应用程序中担任开发人员，主要基于Spring Framework和Java EE（主要是EJB）;但不是所有的层（视图层是我工作的最少）

考虑多层应用程序（客户端层，业务层，数据层等）在哪一层进行数据验证？

我听说过 Bean验证API 即：JSR 303;但验证是在Beans中进行的，即服务器端（如果我理解正确的话）。

那么在应该进行验证的实际应用中呢？是否应该在客户端层本身进行一些验证（例如，如果使用的视图技术是JSP，那么验证是否应该在JSP中进行）？如果是，那么JSR 303的优势是什么。

将数据从客户端传送到服务器因为验证而被拒绝也没有意义，我不清楚验证的正确方法是什么。

理解这一点的任何解释都很受欢迎。

Answer 1

通常，应用程序中有3层。模型层，控制层和视图层。每一层都有它的验证逻辑。

查看图层检查用户输入数据的验证。此检查有助于用户体验和服务器的性能，因为它可以提前指出用户的无效输入并避免无效调用服务器的界面。签入视图层应该主要是关于用户的输入检查（例如：电子邮件格式检查，密码格式检查等）。

控制层检查也是必要的。此检查可以避免非法调用服务器的接口。例如，http请求参数中的登录令牌丢失或无效。

模型层检查主要是关于数据验证。查看图层检查用户的电子邮件格式，模型图层将检查电子邮件是否在应用程序中注册（可能是用户数据存储在db或缓存中）。

总之，每一层都有责任，应该分别进行数据验证。

Answer 2

你是对的，Bean Validation API在业务逻辑层而不是客户端执行验证。通常，数据验证应尽可能接近客户端，最好是在客户端本身也是正确的。

但有时候，你不能在那里做，所以你需要服务器端验证。例如，如何验证登录页面中是否已登录？

有时验证甚至更深入到数据层。例如，数据完整性约束是数据层验证（参照完整性，可空性，......）。

总之，数据验证应尽可能在客户端执行，但有时无法在那里完成。因此，尽管客户端和服务器之间传输数据的成本很高，但您必须在服务器端执行此操作。

Answer 3

因为＆＃34;验证从用户收到的输入以维护数据完整性是应用程序逻辑的重要组成部分，据我所知，Web开发人员总是被鼓励进行两步数据验证，即在UI中也是如此就像在业务逻辑中一样。我来简要介绍一下。

1. 客户端验证的优点是您可以控制在需要的地方警告用户，并立即显示相关消息。但请记住避免复杂的逻辑，例如日期比较作为验证，因为在后端，您将有足够的自由来验证各种约束。
2. 通常在业务层执行后端验证总是更好，后者可以成为应用程序中最强大的部分。这确保了完美的输出，记住抛出自定义异常，使应用程序看起来更好，并利用现有的验证方法{ex。 isDigit（），isEmpty（）etc}。
3. 在数据层级别，尽量减少验证，但有时我们必须包含它们，如果依赖其他服务等。

关于JSR 303，bean验证，它有助于简化对映射到bean的用户输入字段的验证{通常在基于Spring的REST应用程序中}

关于您的疑问＆＃34; 将数据从客户端传送到服务器因为验证而被拒绝是没有意义的＆＃34; ..它可能看起来如此，但以这种方式处理涉及复杂逻辑和异常的验证的流程非常重要。

Answer 4

我认为谈论验证是谈论一种不是解决方案的方法。

一种方法可能是为任何层提供自己的验证。 另一种方法是进行应用程序无关验证。 对前者或后者的选择取决于各种因素：应用程序复杂性，层设计，可维护性，层可重用性。

JSR303是一种验证：bean验证。

其他验证可以是：

• 检查任何注射
• 检查身份验证/授权

关于可重用性：如果您调用依赖客户端验证的业务层，那么B2B不能使用验证。

除了这些考虑之外，还有很好的建议可供遵循。例如don't trust client side validation。

客户端验证对于改善用户体验很有用，但不应用作服务器端验证的替代。