自定义Hibernate业务验证模型：可能存在的风险

Question

我打算创建一个依赖于Hibernate的前后监听器的自定义验证模型。

每个Validation类应包含在执行插入，更新或删除之前需要检查的业务规则（而不是输入检查）。 这就是为什么它依赖于PreInsertEventListener，PreUpdateEventListener，PreInsertDeleteListener等听众。

验证类有时需要检查数据库中的某些内容。我在其他帖子中读到，不建议从Listener插入或更新某些内容？但我打算只做只读通话。

要恢复：

• 验证类与一个特定实体相关;
• Validaton类由Hibernate Listener;
调用
• 验证类可能会在DB中执行一些“只读”调用;
• 验证类在同一个Hibernate Session和Transaction;
中执行
• 当规则不满足时，会抛出一些RuntimeException导致回滚当前Transaction;

这个概念的优点是所有业务规则都可以放在与一个实体特定相关的验证类中。这可以避免业​​务规则分布在不同的服务上。

您如何看待这种方法？我需要注意哪些缺点/风险（特别是与Hibernate相关）？

Answer 1

我认为这里重要的是预测您的验证规则将仅针对持久化的实体。您很可能遇到需要来自父/子实体的数据来验证或获取相关数据的情况。

分布在不同服务上的业务规则是一个真实的案例，通常用于验证您需要调用不同服务的实体。例如，如果您要为帐户保留借记交易，则需要验证帐户持有人是否存在，帐户是否处于有效状态＆amp;帐户有足够的余额。