gpt4 book ai didi

struts Action 类和业务服务层

转载 作者:行者123 更新时间:2023-12-05 00:34:57 25 4
gpt4 key购买 nike

我对处理在服务层上完成的“业务验证”有疑问。下面的代码显示了一个典型的账户资金转账示例,它验证了足够的资金,转账金额小于定义的限制。

在这个例子中,调用者必须处理和捕获 Action 类中定义的异常,并使用相应的 ActionError 来显示错误消息。

对所有业务验证使用异常是“必须的”吗?

如果我决定不为此使用异常,我将不得不在业务层中定义相应的 ActionError(这违反了某种意义上的耦合/内聚)规则。

应该如何处理由服务层传播回 Action 类的消息?

public void transfer(String fromAccount, String toAccount, double amount) throws InsufficientFundsException, TransferLimitException, FactoryException { 
try {
Account from = getAccountHome().findByPrimaryKey(
new AccountKey(fromAccount));
Account to = getAccountHome().findByPrimaryKey(
new AccountKey(toAccount));
if (from.getBalance() < amount)
throw new InsufficientFundsException(); // Add action errors

if (from.getTransferLimit() > amount)
throw new TransferLimitException(); // Add action errors
to.deposit(amount);
from.withdraw(amount);
} catch (Exception e) {
throw new FactoryException(
"cannot perform transfer. Nested exception is " + e);
}
}

最佳答案

您的业​​务应该在模型中处理,您的业务逻辑中遇到的任何问题都应该传播给调用者,在这种情况下是 Struts Action 类。

但是您不想将 Struts 类(Action、ActionForm、ActionError、ActionMessage 等)与模型耦合,因此您基本上有两种方法可以通知调用者任何问题:

  • 返回一些调用者可以检查的错误代码;
  • 抛出一些调用者可以捕获的异常。

  • 更喜欢使用异常(exception) 因为无论在执行链中有多深,它们都可以从业务层内部的任何地方被抛出到顶层。这使业务代码保持干净,因为您不必像第一种方法那样冒泡错误代码。

    然后 Action 类将捕获异常,该类将它们转换为 ActionError 对象以显示在 View 中。只要确保你不要做得太过分,就会结束 throwing the kitchen sink否则你的 Action 类会被过多的 try-catch 块挤满。此外,您可以让异常传播并创建 exception handler某种捕获从下面抛出的所有异常并根据异常类型重定向到适当的 View 。

    关于struts Action 类和业务服务层,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/10063090/

    25 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com