1. 問題の説明
今日、ビッグ C の同級生が私たちのところに来て、技術的な要件を教えてくれました.インターフェースで返されるすべてのフィールドを処理しないようにしましょう.フィールド値が「null」の場合、それを返さないでください.APP がクラッシュします. . えっ?そんな疑問は誰でもすぐに思いつくと思います.前は良かったのに? 今はいきなりGです. しばらくコミュニケーションをとった後、テクノロジーとソリューションの変化が原因であることが判明しました。
2、問題の原因
根本的な理由は、Big C がテクノロジーを最適化し、以前の php コードから golang に移行する必要があることと、古い php コードには、そのレベルで「単語の末尾が null の場合は戻りません」というフィルターがあるためです。この技術的な最適化の後、私はこれをしたくありません。
古い技術ソリューションは次のように実装されています。
新しい技術ソリューションは次のように実装されます。
3. ソリューション
ビジネス アーキテクチャは規範的な議論に対処します。
チームの観点からすると、解決策は 2 つしかありません。彼らは私の個人的なドラマにより適しています。
まず第一に、技術的な最適化を行うことができますが、前提は以前の機能的なものに影響を与えることはできません。そうでなければ、すべてのアクセス アンプを適合させる必要があります。ドッキング リリースを変更する意思があるかどうかは問題ではありませんが、時間があるかどうかは別問題です。
Big C はクライアントを担当するため、クライアントのフィールドの正確性を保証する必要がありますが、実際には、サードパーティ インターフェイスは信頼できません。
ビッグCがこれを行えば、他の事業者は繰り返しのアクションを行う必要がないため、構造もシンプルです。
業務を行うのであれば、どのように行うのか、どのくらい大変なのかという問題もあり、そのような論理処理をグローバルに行うのは Big C 向けの API でないと不可能です。しかし、明らかにそのような建築設計は不可能です。例を考えてみましょう: インターフェイスが Big C に提供され、この論理的な判断が行われますが、ある日、クラスメートが Big C に新しいインターフェイスを提供し、そのような論理処理を行うように誰も彼に思い出させません. テスト中、各フィールドは、その結果、オンライン化後の業務変更により、あるフィールドの値がなくなり、クライアントはG.
ビジネスソリューション:
ビジネス側がこれを行う場合、2 つの方法があります。
1. インターフェイスによって返されるオブジェクトをフィルタリングするには、フィールドまたはオブジェクトに適用できる JsonInclude アノテーションを使用します。
# 引的包
import com.fasterxml.jackson.annotation.JsonInclude;
# 具体注解
@JsonInclude(JsonInclude.Include.NON_NULL)2. グローバル フィルタに従って設定を使用します。
spring:
jackson:
default-property-inclusion: non_nullどちらの方法を使用するかは、状況によって異なります。私が説明した解決策の規範的な議論について意見がある場合は、コメント領域にメッセージを残して議論して議論することもできます. 一緒に進歩しましょう！