在基于企业Java的实际应用程序中应在哪一层进行验证？

Question

我曾在几个主要基于Spring Framework和Java EE（主要是EJB）的企业应用程序中担任开发人员。 但不是所有层（视图层是我研究过的最少的层）

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

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

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

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

理解这一点的任何解释都很好。

Answer 1

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

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

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

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

一言以蔽之，每一层都有它的责任，应该分别进行数据验证。

Answer 2

没错，Bean验证API是在业务逻辑层而不是客户的逻辑层执行验证的。 同样正确的是，通常，数据验证应尽可能地靠近客户端，最好是在客户端本身。

但是有时候，您只是不能在那里做，因此您需要服务器端验证。 例如，如何验证注册页面中是否已进行登录？

有时，验证甚至会深入到数据层。 例如，数据完整性约束是数据层验证（引用完整性，可空性等）。

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

Answer 3

由于“验证来自用户的输入以保持数据完整性是应用程序逻辑的重要组成部分”，据我所知，始终鼓励Web开发人员进行两步数据验证，即在UI以及业务逻辑中。 我告诉你

1. 客户端验证的优势在于，您可以控制在需要时警告用户，并立即显示相关消息。 但是请记住避免使用诸如日期比较之类的复杂逻辑作为验证，因为在后端，您将有足够的自由来对各种约束进行验证。
2. 通常在业务层上执行后端验证总是更好的选择，这可以成为应用程序中最强大的部分。 这样可以确保输出无缺陷，请记住抛出自定义异常，从而使应用程序看起来更好，并利用现有方法进行验证。 isDigit（），isEmpty（）等}。
3. 在数据层级别，尝试最小化验证，但是如果对其他服务等有依赖性，有时我们必须包括它们。

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

关于您的疑问，“ 由于验证而拒绝从客户端到服务器的数据传输也没有意义 ” ..看起来应该如此，但采用这种方式处理涉及复杂的验证的流程确实很重要逻辑和例外情况更好。

Answer 4

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

一种方法可能是在任何层都有自己的验证。 另一种方法是进行应用程序不可知的验证。 前者还是后者的选择取决于多种因素：应用程序复杂性，层设计，可维护性，层可重用性。

JSR303是一种验证类型：bean验证。

其他验证可以是：

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

关于可重用性：如果调用依赖客户端验证的业务层，则呼叫B2B无法使用验证。

除了这些考虑因素之外，还有一些好的建议可以遵循。 例如，不要相信客户端验证 。

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