使用复杂业务逻辑和远程服务调用的Bean验证
我正在为一个web应用程序实现一个相当复杂的输入验证，它应该输入一个ID，并将调用其他几个系统，以便在持久化包含该ID的对象之前检查该ID是否有效。我想使用bean验证，但后来我发现自己专门创建了一个bean来允许这种验证发生。事实上，为了进行远程服务调用，我不仅需要向验证器提供ID，还需要提供一些上下文信息。
您认为bean-validation始终是正确的验证位置吗，即使它很复杂并且需要Bean范围之外的上下文来验证？
实现业务逻辑验证规则的Spring服务会是更好的选择吗？
共有1个答案
Bean验证最适用于检查用户从web表单输入的正确性。
如果必须在其他系统中验证用户输入，则应将其作为算法中的常规步骤来实现。
Bean验证的发明是为了用像@min(1)这样优雅的简短注释来代替像if x！=null&&x<0 then doReject()这样的琐碎、枯燥的手动验证
-
问题内容： 软件体系结构中的域对象和域服务是什么？我不熟悉它们，或者它们与业务逻辑层有何不同？ 问题答案： 不同的人以不同的方式使用这些术语，但这是我的看法： 1）“业务”和“域”大致是同义词。“域”更为通用，因为它不会假设您正在编写业务应用程序。因此，如果我们正在编写科学应用程序或游戏，则可能更喜欢将代码的相关部分称为“域”代码，而不是“业务”代码。因此，在本说明的其余部分中，我将使用“域”，因
-
我有一个struts项目，我的客户给了我完整的业务逻辑类。他需要这个忘恩负义的人，昂首阔步，冬眠。 哪一种最好，要将业务逻辑放到我的Dao层，需要为业务逻辑添加一个附加的服务层。 一些strut项目我发现动作类直接访问道。 请建议我哪个更好choice.help高度赞赏。 谢谢，
-
问题内容： 我的应用程序中有两层验证。首先是由bean验证API执行的实体验证（例如，必填字段）。第二层是业务逻辑验证。例如，用户有一个帖子。用户只有自己是该帖子的创建者，并且帖子评级小于50，才能删除该帖子。因此，我必须执行以下操作： 我不喜欢这种方式，因为这种条件被重用，而且我不得不重复代码。此外，如果条件数大于5左右，那么阅读和理解代码就变得不现实。 此外，标准的Spring Validat
-
问题内容： 我想在两次调用getter和setter之后编写我的业务逻辑，因为我在业务逻辑中使用了它们的对象值。但是，在吸气剂之前调用了Construct，Post构造，actionevents..。 那么，如果我不想在内部获取业务逻辑，该如何使用它们的值呢？ 问题答案： 我想导航到该站点并从显示在outputText中的数据库中获取数据。 在bean的（后）构造函数中执行该工作。 与 当我更改（
-
答案可能涵盖所有框架，但我对SpringMVC案例特别感兴趣。我正在重构一个访问内部数据库和远程服务的服务层。这些方法应该是事务性的，它们需要来自远程服务的数据。下面是类似的伪代码： 这样更容易实现。但是有许多缺点，例如当远程服务调用失败时不必要地创建和回滚事务，由于远程服务调用而导致的事务更长，并且可能更复杂。我正在考虑将服务调用移动到单独的非事务性方法，并调用事务性方法，如下面的代码段所示 假
-
综述 在多功能的动态web应用程序中测试业务逻辑漏洞需要用非常规手段来思考。如果应用认证机制原先以1、2、3的步骤依次执行的验证身份目的来开发，万一用户从步骤1直接跳到步骤3会发生什么？用更加简单的例子来说，在打开失败、权限拒绝或仅仅500的错误的情况下，应用程序是否依然能够提供访问权限？ 可以举出许多例子，但是不变的思想是“跳出常规思维”。这种类型的漏洞无法被漏洞扫描工具探测到，依赖于渗透测试人