4

サービス層で行われる「ビジネス検証」の処理について質問があります。以下のコードは、十分な資金があることを検証する典型的な口座送金の例を示しています。送金金額は、定義された制限よりも少なくなっています。

この例では、呼び出し元は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); 
    } 
}
4

1 に答える 1

6

ビジネスはモデルで処理する必要があり、ビジネスロジックで発生した問題はすべて、呼び出し元（この場合はStrutsアクションクラス）に伝播する必要があります。

ただし、Strutsクラス（Action、ActionForm、ActionError、ActionMessageなど）をモデルと結合したくないので、基本的に、呼び出し元に問題を通知する2つの方法があります。

  • 呼び出し元が確認できるいくつかのエラーコードを返します。
  • 呼び出し元がキャッチできるいくつかの例外をスローします。

例外は、実行チェーンの深さに関係なく、ビジネスレイヤー内のどこからでも最上位レイヤーにスローできるため、私は例外を使用することを好みます。これにより、最初のアプローチの場合のようにエラーコードをバブルアップする必要がないため、ビジネスコードがクリーンに保たれます。

次に、例外はActionクラスによってキャッチされ、ActionクラスはそれらをActionErrorオブジェクトに変換して、ビューに表示します。それをやり過ぎて台所の流しを投げてしまうことがないように注意してください。そうしないと、アクションクラスが過度のトライキャッチブロックで混雑します。さらに、例外を伝播させて、下からスローされたすべての例外をキャッチし、例外タイプに基づいて適切なビューにリダイレクトする、ある種の例外ハンドラーを作成することができます。

于 2012-04-16T15:25:40.487 に答える