インターフェイスの統一されたリターン
次の図に示すように、会社のインターフェイスを開発する場合、コントローラー層のインターフェイスリターンを結果にラップする必要があることがわかります。
インターフェイスを作成する場合でも、グラフィックコードでインターフェイスをクエリする場合でも、ここで結果を受け取る必要があります。結果の構造を見てみましょう。
この結果にはいくつかのフィールドがあります。
「「」
コード：ステータスコード
メッセージ：ステータス情報
data：返されたデータをロードします
例外：異常なデータ
次に、インターフェイスをテストして、戻りスタイルを確認します。
インターフェイスを呼び出します。戻り形式は次のとおりです。
{
"code": 200,
"message": "SUCCESS",
"data": {
...
}
"exception": xxx
}
書いた後、私はすべてのインターフェースを結果のレイヤーでラップする必要があると考えていました。これはインターフェースの読みやすさに影響します。開発として、このように1つのレイヤーをラップすることも非常に面倒です。
「「では、フレームワークを介してResultのレイヤーを自動的にラップし、コントローラーレイヤーでエンティティを直接返す限り、それを開発する方法はありますか？
」
コントローラー層インターフェースの統一されたリターンを実現できるような方法が実際にあります。
上記のコードのようResponseBodyAdviceに、Controllerレイヤーメソッドのデフォルトの戻りパラメーターをインターセプトするために使用します。率直に言って、それは迎撃機です。これは主にbeforeBodyWrite()メソッドに依存します。このメソッドでは、コントローラーでの戻り値がすでに結果である場合、結果は直接返されます。そうでない場合は、結果を使用してラップします。
効果を見てみましょう：
上記のコードのように、エンティティを直接返します。Swaggerの戻り値を見てみましょう。
swaggerによって返される形式は、インターセプターの形式です。
「「ここで別の質問があります。通常のインターフェイスの戻り値はResultによってラップされています。インターフェイスが例外をスローした場合、どのようにして同じ形式を返すことができますか？
」
グローバル例外キャプチャ
ここでは、グローバル例外キャプチャが必要です。グローバルな例外キャプチャに関して、私は多くの子供靴が知っていると信じています：
キャプチャクラスを@ControllerAdvice作成し、それにアノテーションを追加してから、例外を処理するメソッドを作成する必要があります。
ここでは、@ResponseBodyアノテーションと@ExceptionHandlerアノテーションを追加しvalue = Exception.classます。これは、タイプExceptionの例外をキャッチすることを意味します。例外を直接スローできます。
次のように投げることもできます：
コードが例外をスローした場合、インターフェイスは次の値を返すかどうかをテストします。
フォーマットは期待通りです。
しかし、ifステートメントを書く必要があるたびに、ここにはまだ問題があります。
if(条件) {
throw new RuntimeException("...");
}
このように書くのはまだ面倒で、すべてが捨てられますRuntimeException。これはまだラフすぎます。
そこで、ビジネス例外をカスタマイズし、いくつかの例外スローメソッドをカプセル化して、必要なことは何でもすることにしました。
カスタムビジネスの例外
例外ステータスコードと例外情報データをカプセル化するビジネス例外を定義します。
例外を正常にスローします
次に、ビジネス例外判断クラスを作成します。
ここではコードの一部のみがインターセプトされます。実際には、メソッドcheckArgument()とは2つしかありませんcheckNotNull()。彼らは何のために良いですか？空でないチェックを実行する場合は、通常、次のように実行されます。
if (updateEntity == null) {
throw new RuntimeException("传入参数为null");
}
しかし今、あなたはこれを行うことができます：
BusinessExceptionAssert.checkNotNull(updateEntity, "参数不能为null");
スローされるのは、私のカスタムビジネス例外です。
一般的なロジックチェックの場合はどうなりますか？前のコードは次のように書かれています：
if(!"1".equals(id)) {
throw new RuntimeException(String.format("参数id【%s】只能为1",id));
}
より洗練された実装が可能になりました。
BusinessExceptionAssert.checkArgument("1".equals(id), 500, "参数id【%s】只能为1",id);
ビジネス例外がスローされるため、例外コードをカスタマイズすることもできます。
完全なテストコード：
@ApiOperation(value = "test-测试异常", httpMethod = "POST", notes = "测试代码，勿动")
@PostMapping(value = "testBusinessException")
public int testBusinessException(@RequestParam String id) {
BusinessExceptionAssert.checkArgument("1".equals(id), 500, "参数id【%s】只能为1",id);
return 1;
}
私たちのテスト結果：
期待に沿って。
この記事はここにあります、この記事は主に説明します：
「「」
インターフェイスの統一されたリターンを実現する方法
ビジネスの例外をカスタマイズして一律にキャッチする方法
例外を適切にスローする方法
改善点があれば、積極的にコミュニケーションをとってください。