【问题标题】:Validation errors handling from EJB in JSFJSF 中 EJB 的验证错误处理
【发布时间】:2013-11-22 13:02:12
【问题描述】:

我想知道在中型/大型 Java EE 应用程序中处理验证错误的最佳方法是什么。

假设我已经管理 bean 和外观,如下所示。

class SomeManagedBean {

    @EJB
    SomeFacade someFacade;

    public void performSomeAction() {
        (...)
        someFacade.businessAction(loggedUser, editedEntity);
        (...)
    }

}

class SomeFacadeImpl {

    public Object businessAction(User user, Entity entity) {
        if (!isInCorrectStateToDoAction(entity)) {
            // error A
        }
        (...)
        if (!hasRightToDoAction(user, entity)) {
            // error X
        }

        doAction(user, entity);
    }

}

我希望 SomeFacade 的 businessAction 应该验证他们的输入并检查它是否可以使用给定的参数执行此业务操作。这是因为我可能在应用程序的几个地方使用这种业务方法,我不想复制验证码。

假设我想使用 FacesMessage 向客户端提供有关验证错误的信息。

一些解决方案:

  • 异常 - 当参数有问题时,我只是抛出一个异常
    • 所以我必须抛出 IncorrectStateForActionException, NoRightToDoActionException
    • 为什么不:我只能抛出一个异常,所以我无法通知用户以下几件事:“您没有权限”、(...)、“实体状态不正确”
    • 不应使用异常来提供应用程序的逻辑
  • 一些结果类

    class Result<T> {
        T returnedValueFromMethod;
    
        List<ProcessingError> errors;
    }
    
    • 现在我的业务方法的定义如下:

      public Result<Object> businessAction(User user, Entity entity) 
      
    • 当出现问题时,我会在结果中添加错误信息

    • 当一切正常时,我将返回值放入我的 Result 对象并返回此对象
    • 为什么不呢:这似乎是一种结构相当复杂的“错误代码”。由于该建议告诉“将错误代码更改为异常”,因此我们希望避免它是可以理解的。
  • 我们可以在外观和控制器中进行验证
    • 为什么不:重复的代码
  • 仅在控制器中验证和外观中的操作
    • 为什么不:当我们在代码的其他地方使用这个 businessAction 方法时可能会很危险
  • 我们可以在facade中做两种方法:validation和action(Query Command Separation)
    • 验证结果应该包含所有可能发生的错误,所以它的结构很奇怪
  • 我们可以做几种验证方法(从 A 到 X 的错误)
    • 提供错误消息很容易
    • 但这种解决方案似乎很愚蠢
  • 还有其他想法吗?

最好的解决方案是什么?

【问题讨论】:

    标签: java jakarta-ee ejb


    【解决方案1】:

    在业务层进行身份验证/验证,并让它在失败的情况下抛出异常。您可以在 JSF 操作方法中处理它。

    例如

    @EJB
    private SomeService service;
    
    public void someAction() {
        try {
            service.doSomething();
            addGlobalInfoFacesMessage("Doing something succeed!");
        } catch (SomeBusinessException e) {
            addGlobalErrorFacesMessage("Doing something failed with {0}", e.getMessage());
        }
    }
    

    或者,您可以放手让容器通过特定的&lt;exception-type&gt; 上的&lt;error-page&gt; 处理它。

    对于自己执行身份验证和验证,Java EE 堆栈提供了诸如 JAAS @RolesAllowed 用于身份验证和 JSR303 @NotNull@Size 等注释用于模型。这应该会减少服务方法本身内的if 检查样板。

    【讨论】:

    • 恐怕这还不够。 (1)正如我之前所说:我想避免使用异常来控制程序流,(2)无论我使用 JAAS(那已经太晚了)或 Java Bean Validation 都会有很多可能的不同错误EJB 中的方法。我想通知用户所有这些,而不是首先验证这一点
    • (3) 至于错误页面,我希望用户留在他所在的页面,并为他提供纠正错误/错误的能力。
    猜你喜欢
    • 2014-04-11
    • 1970-01-01
    • 1970-01-01
    • 2017-08-19
    • 2017-07-04
    • 1970-01-01
    • 1970-01-01
    • 2020-08-23
    • 1970-01-01
    相关资源
    最近更新 更多