在业务层返回业务验证结果的首选方法是什么答案

【问题标题】：what is preferred approach to return business validation results in business layer在业务层返回业务验证结果的首选方法是什么
【发布时间】：2011-07-13 11:39:42
【问题描述】：

假设我们有一个使用某种业务层（EJB、Spring 服务等）的客户端应用程序（Web 或独立）。假设用户想要执行一些业务逻辑（例如创建一些东西）。这个操作有一些先决条件，比如数据格式，数据库中其他对象的存在，权限等。那么这个业务逻辑层的最佳设计是什么，我的意思是如何返回验证错误，指示成功，返回意外错误等？

我知道的方式：

对于验证错误返回例如具有状态和违规列表的 OperationResult 对象，

成功：状态=成功且错误列表为空的 OperationResult，

对于意外错误抛出运行时异常

对于验证错误抛出 ValidationException（runitme 或已检查？）具有违规列表

成功：如果需要，无效或创建实体

对于意外错误抛出运行时异常

我知道有两种基本方法，但每次我开始写作时，我都很难把它做好。

【问题讨论】：

标签： java validation exception jakarta-ee business-logic

【解决方案1】：

我对验证异常方法有反感，毕竟验证错误中没有什么异常，所以我发现很难证明为此使用异常是合理的。所以从理论上讲，唯一有效的选择是第一个。

话虽如此，尽管这取决于您使用的验证框架*，但编写异常版本通常要容易得多。

是否应该检查您的验证异常（如果您正在使用一个）是否会打开另一罐蠕虫，有些人通常非常反对检查的异常，其他人会说完全相反。为了我的两分钱，我相信运行时异常应该保留用于编码错误，并且应该尽可能检查“预期”异常。但我必须强调，这只是代表我的个人喜好。

*如果您有多个验证器都必须在验证阶段运行，则异常不是很有效。如果您打算在第一个失败的验证步骤处停止，则异常更容易实现并且可能更具可读性。

【讨论】：

我同意。最好列出验证错误，然后在最后抛出异常（如果列表不为空）。将列表附加到例外。列表还允许您向用户显示“警告”，因此您可以有一个额外的参数来确认警告并继续进行......
@Ben，如果是这样，应该检查 ValidationException 还是运行时？如果选中，用户需要处理它，它有时会在他的代码中搞砸很多（太多的 try/catch 块）。明确返回具有违规列表的状态对象类型，如 1) 版本不是更好吗？
另一方面，拥有灵活的 ValidationException 层次结构在客户端（以正确的方式捕获并处理每个）比简单的违规列表更好。
@bottle 正如您所指出的，与结果对象不同，异常会强制客户端对其进行操作。这是否是一件好事可以争论，但我认为是。如果客户端有太多的 try-catch 块，它可能应该重新组织以以通用方式处理和显示验证错误。但是，如果您已经有一个模块来处理所有错误，那么您就不需要再有异常了。 :)