3

ビジネス層に次のメソッドがあるとします。何か問題が発生したことを UI レイヤーに伝え、エラー メッセージも表示するベスト プラクティスは何ですか? メソッドは OK のときに空の文字列を返す必要がありますか、それ以外の場合はエラー メッセージを返す必要がありますか?それとも、キャッチされた例外をラップする catch コードで別の例外をスローする必要がありますか? 2 番目のバリアントを選択すると、UI に別の try,catch が表示されるはずです。最初の亜種の疑似コードを次に示します。

public String updateSomething()
{
   try
   {
      //Begin transaction here
      dataLayer.do1();
      dataLayer.do2();
      dataLayer.doN();
      //Commit transaction code here
   }
   catch(Exception exc)
   {
      //Rollback transaction code here
      return exc.message;
   }

   return "";
 }

これは良い習慣ですか、それともキャッチで別の例外をスローする必要がありますか (メソッドは無効になります)?

4

4 に答える 4

5

ビジネス レイヤーから UI レイヤーに標準コントラクトを返すのが好きです。

次のようになります。

public class ServiceOperationResult<T>
{

    public bool Successful
    {
        get; 
        set;
    }

    public ServiceErrorType ErrorType
    {
        get;
        set;
    }

    public string ErrorMessage
    {
        get;
        set;
    }

    public T ReturnData
    {
        get;
        set;
    }
}

私はジェネリックを使用して、すべてのサービスが何を返すかを定義できるようにします。また、標準のエラー フラグは、発生したエラーの種類をクライアント アプリに伝えます (これらは、「内部エラー」、「外部パーティ エラー」、「ビジネス エラー」などのメタタイプです)。ルールの検証エラー") が表示され、アプリはこれらのエラー タイプに対して標準的な方法で対応できます。

たとえば、ビジネス エラーは赤いエラー ラベルで表示されますが、内部エラーはエラー ページにリダイレクトされるか (Web アプリの場合)、フォームを閉じます (Windows アプリの場合)。

私の嫌いなところは、Web サイトで赤いラベルが表示され (検証エラーが表示されると予想される場所)、「データベース サーバーが接続を拒否しました」のようなメッセージが表示されることです。これは、エラー データを返すために文字列のみを使用して実行するリスクです。

于 2010-03-27T08:25:09.693 に答える
2

最善の方法は、例外をより一般的な型でラップして再スローすることです。したがって、updateSomething() は何らかの例外 (たとえば、UpdateFailedException) をスローできることを宣言する必要があり、catch ブロックで例外をラップする必要があります。

public String updateSomething() {
  try {
    [...]
  } catch ( SQLException e ) {
    // rollback;
    throw new UpdateFailedException(e);
  }
}

しかし、抽象的な例外タイプをキャッチするのは得策ではありません。セマンティックを知っているものだけをラップする必要があります。例: SQLException、DataAccessException (Spring DAO) など。

Exception をラップすると、NullPointerException の InterruptedException を簡単にラップできます。そして、これはあなたのアプリケーションを壊す可能性があります.

于 2010-03-27T08:19:12.750 に答える
1

このように String を返すのは少し珍しいことです (ただし、そうしない本当の理由はありません)。より一般的な方法は次のとおりです。

  • ブール値を返し、ログに記録するか、グローバルな「最後のエラー」値を設定するか、更新するメソッドにエラー構成へのポインターを渡すことにより、エラーメッセージを設定する何らかの方法があります。

  • 失敗時に例外をスローするvoidメソッドを持ち、呼び出し元のコードでそれを処理します（提案どおり）

上記の両方が広く使用されているのを見てきました。どれが「ベスト」かは難しいです。作業している言語のイディオムや慣習、および/または作業している既存のコード セット/ライブラリがあれば、それと一貫性を保つようにしてください。

于 2010-03-27T08:17:05.833 に答える
0

おそらく最善の方法は、レイヤーに固有のカスタム例外クラスを用意することです。特定のレイヤーで例外をキャッチすると、カスタム例外を呼び出し元のレイヤーにスローします。これにより、次の利点が得られます。

  1. 例外に対処するためのより良いモジュラーアプローチが得られます。
  2. コードの複雑さが増すと、コードのメンテナンスが容易になります
  3. 例外シナリオをより細かく制御できます

たとえば、ビジネス層で例外をキャッチし、プレゼンテーション層に通知したい

public string DummyFunction
{
   try
   {

   }
   catch(Exception ex)
   {
      throw new businessException();
   }
}
于 2013-07-28T18:52:05.920 に答える