web-dev-qa-db-ja.com

サービス層でのDao例外の処理

DaoレイヤーがDao固有の例外をスローする場合、サービスレイヤーでそれらを処理すると、懸念の漏洩が発生しますか？はいの場合、例外を一般的で、それを処理するためにどのレイヤーからも独立させる必要がありますか、それとも他の方法がありますか？

サービスレイヤーによってスローされた例外を処理するUIレイヤーにも同じ質問が当てはまります。

javaserviceexception-handlingdao
24
shrini1000

レイヤードアプリケーションを作成する場合、常にユーザーレイヤーと使用される別のレイヤーがあります。この場合、UI層->サービス層を使用-> DAO層を使用します。

今では、非常に主観的であり、解釈を受け入れることができます。しかし、目的は適切な程度のデカップリングである必要があります。これを達成するための1つの方法は、defineジェネリックレイヤー固有の例外PersistentException、ServiceExceptionなどと言います。これらの例外は、実際のレイヤー固有の例外をラップします。

たとえばデータベース側にエラー（制約違反など）がある場合は、それをPersistentExceptionでラップし、サービス層に処理させます（方法これを一般的な方法でUIレイヤーに伝えます）

これで、サービスレイヤーとDAOレイヤーの間の統合が契約（インターフェースベース）であるため、DAOレイヤーは-に従う限り、自由に実装を変更できます。 インターフェース規約。したがって、いくつかの新しい例外をスローする実装を変更した場合、それらの新しい例外はPersistentExceptionにラップされ、サービスレイヤーは影響を受けません。

34
Santosh

はい。レイヤーごとに独自の例外を作成することをお勧めします。

たとえば、特定のDAO実装を使用している場合は、実装固有の例外を独自の一般的な例外にラップして、サービスレイヤーに転送する必要があります。

ただし、独自の例外の階層を作成する際は、アプリケーション開発のオーバーヘッドにならず、サービス層で必要な情報を維持できるようにする必要があります。ほとんどの場合、一般的な例外を含むカスタムエラーコードで十分です。

このようなものを使用して、実装固有の例外をシミュレートし、サービスレイヤーにスローできます。

class AppDAOException extends Exception {
    public final static int _FAIL_TO_INSERT = 1;
    public final static int _UPDATE_FAILED = 2;
    public final static int _SQL_ERROR = 3;
    private int errorCode;
    public AppDAOException(int errorCode) {
        this.errorCode = errorCode;
    }
    public getErrorCode() {
        return errorCode;
    }
}

DAO実装からのスロー：

try {
   //code here
} catch (some.impl.SQLSyntaxException e) {
   throw new AppDAOException (AppDAOException._SQL_ERROR );
}

懸念の漏洩について：次のようなすべての例外について、サービス層に迷惑をかけたくない場合があります。

} catch(NoRowExistsException e) {
    return null;
} finally {
   //release resources
}

したがって、アプリケーションのニーズに基づいて呼び出しを行う必要があります。

9
Husain Basrawala

次のような操作を行うと、DAOレイヤーはすでにサービスレイヤーにリークしています。

userDAO.persist(user);

例外は、操作と同じようにAPIの一部であるため、同じように考える必要があります。

try {
    userDAO.persist(user);
} catch (DAOException e) {
    // looks fine to me
}

実行時の例外、または例外を再スローしたときにリークが発生する可能性があります

try {
    userDAO.persist(user);
} catch (SQLException e) {
    // sql implementation exposed
}

しかし、これでも「レイヤーに依存しない」例外よりも良さそうに聞こえます

6
Roger Keays

良い質問..！！ UIレイヤー（たとえば、Strutsを使用している場合はアクションレイヤー）で例外を処理することは、優れたアプローチです。例外を一般的にすることは、この問題に対処する良い方法ではありません。ただし、すべてのレイヤーには、ジェネリックとしての特定の例外があります。たとえば、DAOレイヤーには、DavaSavingException、IOExceptionなどのカスタム例外ハンドラーがある場合があります。

したがって、このアプローチでは、DAOからサービスレイヤーに例外がスローされ、UIレイヤーに再びスローされて、UI固有のクラスがキャッチされます。

しかし、物事はあなたのアプリケーション/ニーズによってはあまりにも外交的です。

0
Ved