3

なんらかの理由で例外をスローするのは好きではありません。おそらくパフォーマンスへの影響が原因で、この問題を再考する必要があるかどうか疑問に思っています。

サービス レイヤー (Dao の + ビジネス ロジックなどを使用) が例外をスローする必要がありますか?

public ModelAndView createProduct(@Valid ProductForm productForm, ..) {
  ModelAndView mav = new ModelAndView(...);

  if(bindingResult.hasErrors()) {
     return mav;
  }

  // throw exception if user doesn't have permissions??
  productService.create(product, userPermissions);

}

したがって、ProductService の create メソッドのオプションは次のとおりです。

  1. ユーザーに権限がない場合は、例外をスローします
  2. 成功した場合は、成功/失敗フラグとエラー コレクションと共に、新しい製品 ID を持つある種の Response オブジェクトを返します。

注意事項:

このサービス レイヤーは、Web 以外のアプリや安静な Web サービスでも再利用できます。

ベストプラクティスと見なされるものは何ですか?

4

3 に答える 3

6

サービスと例外の意味によって異なりますが、コンテキストでは、HTTP エンドポイントからの Java 例外を想定します。

答えはノーだ。サービスは、一般的な方法でエラーを公開する必要があります。Restful サービスの場合、エラーはエラー コードを含む HTTP ステータスとして伝達される必要があります。サービスは、実装の詳細を消費者に漏らしてはなりません。自然の境界です。

コンシューマーは、これらのエラー状況を処理し、それを伝える最も適切なものを決定する必要があります。例外を生成することを選択することもできます。ただし、これらの例外は、サービスがエラー コードを返す原因となった元の問題/認識とは無関係です。

さらに言えば、@yahir の言うことも正しいと思います。HTTP サービスは HTTP エラーを公開し、その下で別の種類のエラーを返す別のサービスを使用している可能性がありますが、その仕事はそれらを適切に処理またはマッピングすることです。

于 2012-05-01T21:17:55.430 に答える
1

他にどのようなオプションがあるか自問してください。例外が必要な場合もあります。他にできる唯一のことは、失敗または成功のステータスを返し、適切に処理することです。

于 2012-05-01T21:11:34.063 に答える
0

サービス層は、クライアント コードに公開されている他のメソッドと同じように動作する必要があります。結局のところ、それはまさにそれです。

RPC を介してそれを使用するクライアントは、まさにこの動作を期待します。

REST などの他のクライアントは、いずれにせよ、他のラッピング レイヤー (Controllerレイヤーなど) を介してサービス レイヤーにアクセスする必要があります。このラッピング レイヤーの役割の 1 つは、応答をクライアントが使用できるように変換することです。

于 2012-05-01T21:25:50.203 に答える