休憩DAO設計と例外処理

Question

私はREST WSを呼び出すDAOを設計する必要があります。 このWSは、指定されたユーザー名とパスワードからユーザー資格情報を戻す必要があります。

ケース1：ユーザーが見つかりました=> REST WSがhttpコード200と資格情報応答を送信します。

ケース2：ユーザーが見つかりませんでした=> REST WSはhttpコード400と原因のエラーオブジェクトを送信します。

ケース3：ユーザーは見つかりましたが、彼のアカウントは無効になっています=> REST WSはHTTPコード400とエラーオブジェクトを原因で送信します。

ケース4：REST WSはREST WS応答をマッピングするための私のDAOでの最良の方法は何

利用できないのですか？

1 - エラーオブジェクトのケースを処理するために私のDAOでfuntionnalチェック例外をスローし、通常の場合にクレデンシャル応答オブジェクトを返します。 REST WSが利用できないときは、未チェックの例外がスローされます

2 - サービス層のジョブであるため、DAOにfunctionnal例外をスローしません。私は、REST WSが返すもの、つまり証明書の応答とラップされたオブジェクトのエラー応答などを返します。サービスレイヤにこれらのオブジェクトが正しいジョブを行うかどうかをチェックさせます。 REST WSが利用できないときは、チェックされていない例外がスローされます。

3 - 私はエラーの場合にチェックされていない例外をスローします。そして私はCredentialsの返答のみを返します。

ありがとうございます。

Answer 1

私はDAOがリモートデータソースが何を返すのかを理解する責任があるので、私はオプション1を優先します。サービス層はDAOの上にあり、リモートソースの複雑さを理解する必要はありません。これには、エラーがワイヤを介して返される方法も含まれます。

Answer 2

HTTPプロトコルの4XXレスポンスはクライアントエラーとして定義されており、DAOレイヤーで例外をスローすることができます。エラーオブジェクトは、スローされた例外の表現です。

チェック済みまたは未チェックの例外をスローする必要がある場合は、長い議論の基礎となります。最終的には、プロジェクトの個人的な好みまたは一般的なコーディングガイドラインに依存します。例外をスローすると、例外タイプをHTTPエラーコードにマッピングできます。 BadCredentialsExceptionがHTTPエラー400になりましたマップできないものが500内部サーバーエラー