3

簡単なスタイルの質問があります。私が書いているアプリケーションには、ブロックの結果に依存するブロックの外部関数だけでなく、try/catch ブロックを含むいくつかのクラス メソッドがあります。例 (疑似コード):

try {
   start_transaction;
   persist_data;
   stop_transaction;
}
catch {
   rollback_transaction;
}
finally {
}

if (transaction_successful)
   send_message;

トランザクションが成功したかどうかをテストするために考えられる唯一の方法は、try catch ブロックでメソッド変数フラグを設定し、if ステートメントでテストすることです。もちろんこれでうまくいきますが、従来の「知恵」とは何なのか知りたいです。「send_message」は try catch ブロックにあるはずですが、これは不要な混乱かもしれません。これはかなり単純な質問だと思います-コードが適切に構造化/整理されていることを確認しようとしているだけです。

4

4 に答える 4

4

ソフトウェアの適切な階層化/このクラス/メソッドの結束の増加についてもう少し考える必要があるようです。提供された例から、ここでは DAL/ビジネス レイヤー ミックス (持続性 + いくつかのビジネス アクティビティ) があるように見えます。これが、catch ブロックの直後に、同じメソッドでトランザクションの結果に反応する必要がある主な理由です。

適切なレイヤリングを使用すると、次のようになります。

  • 永続性が失敗します。呼び出し元のレイヤーにチェック/ランタイム例外をスローして、この事実を示します (失敗を正確に示す方法を決定するのはあなた次第です。アーキテクチャのアプローチによって異なります)。
  • クラスを呼び出すと、例外がキャッチされ、エラー処理が実行されます。または、' persisting ' メソッドの呼び出しの直後に、対応するtryブロックでメッセージが送信されます。

もちろん、フラグを設定して（提案したように）、AOPアドバイスを使用してそのような状況を処理できます（特に「send_message」が補助機能の場合）。

于 2012-07-12T02:30:12.657 に答える
1

tryブロックに入れるのは簡単です。「乱雑なコード」は個人的な好みの問題ですが、これにより物事がシンプルになります。

于 2012-07-12T02:19:44.620 に答える
1

(これはあなたのコードからかなり明白に見えますが) トランザクションが成功した場合にのみメッセージを送信しようとしていると仮定すると、それを try ブロック自体の一部として配置することは理にかなっていると思います。

私の意見では、メッセージは成功時に送信する必要があるため、「不必要な混乱」にはなりません。トランザクションが失敗した場合でもメッセージに送信する部分がある場合、フラグを保持してトランザクションのステータスを追跡することは明らかに理にかなっています (それに応じてメッセージを変更します) 。

于 2012-07-12T02:22:30.447 に答える
1

ブロック内に配置しtryますが、実行中に例外がスローされた場合send_messageに備えて、独自のcatchブロックを用意することをお勧めします。これは、適切な例外クラスを指定することによって行われます。

于 2012-07-12T02:22:56.387 に答える