私の設計では、一般に DAO 層は例外を処理せず、サービス層が DAO 層を呼び出して例外をキャッチし、ステータス コードを通じて情報をアクション層に返します。 個人的には、Action 層のロジックはできるだけシンプルであるべきだと感じています。Action はインターフェイス層であり、インターフェイスが提供する機能を一目見ただけでは複雑すぎるためです。
あなたの例では問題ありません。 しかし、何かがある場合は問題になります。 宣言的なものを使用している場合、エラーが発生するため、トランザクションの中間リンクでエラーが発生します。は直接スローされるため、トランザクションが開始されたレベルでキャッチでき、現在のトランザクション内のすべての操作をロールバックできます。 dao で例外をキャッチした場合、それを検知するのは非常に面倒になります。ビジネスをロールバックする必要があるかどうか、各 dao 操作の結果を判断する必要があります。
私の設計では、一般に DAO 層は例外を処理せず、サービス層が DAO 層を呼び出して例外をキャッチし、ステータス コードを通じて情報をアクション層に返します。
個人的には、Action 層のロジックはできるだけシンプルであるべきだと感じています。Action はインターフェイス層であり、インターフェイスが提供する機能を一目見ただけでは複雑すぎるためです。
エラー コードは手続き型言語では非常に一般的ですが、オブジェクト指向プロシージャでは、エラー コードをもう少し処理するために例外が使用されます。
エラーコードを使用するデメリットは次のとおりです。
1. エラー検出は必須ではありません。
2. コードにはさまざまな if else エラーコードの判定が含まれます。
例外を使用する利点は次のとおりです。
1、エラー検出は必須であり、例外を処理またはスローする必要があります
2. コードはさまざまなステータスコードを判断する必要はありません。例外が発生した場合は、直接スローされて操作を終了します
3.エラーのスタックです。
ライブラリは例外をスローし、ビジネスはエラー コードを返します。
これは主に 2 つの点に依存すると思います: 1. 各層のロジックの量は自分で選択する必要があります。2. 個人的なスタイルです。私はできる限りビジネス層で処理することを好みますが、daoレイヤーは例外のみをスローします。実際、クライアントに直接返されない限り、どこでも処理できます。
ビジネス層は、例外が発生する可能性があるため、データを返す前にデフォルト値を設定する必要があります。データベースとネットワークの方が大きいため、dao に含める必要があります。例外ビジネス レイヤー/アクションは、クラス内で null/デフォルト値を適切に返し、よりユーザー フレンドリーです
永続化は一般に論理処理を行わないので、上位レベルに投げるのが最善です。そうしないと、将来何らかの永続化フレームワークを使用する必要があります。
たくさんありますが。例外が発生するような状況では、結果が失敗したということになりますが、なぜ失敗したかは開発者が判断することなので、それほど多くの結果を直接返す必要はないと思います。開発者は、どの例外を見て原因を判断することもできます。
何か問題が発生した場合に、これを記録してエラーが発生した場所を特定するのが一般的ですよね。 、例外などをログに追加します
ネストされたレベルは何レベルですか?
まずネストを減らす方法を学びましょう
さらに、サービス層は例外とビジネス ロジックを処理する特定の結果を返します
。アクション層はサービスを呼び出して直接返すだけです
Zhihuでこの質問をしました:https://www.zhihu.com/question/36278363
参照してください。
あなたの例では問題ありません。
しかし、何かがある場合は問題になります。
宣言的なものを使用している場合、エラーが発生するため、トランザクションの中間リンクでエラーが発生します。は直接スローされるため、トランザクションが開始されたレベルでキャッチでき、現在のトランザクション内のすべての操作をロールバックできます。
dao で例外をキャッチした場合、それを検知するのは非常に面倒になります。ビジネスをロールバックする必要があるかどうか、各 dao 操作の結果を判断する必要があります。