エラーチェックの実装の考え方について、考える機会を頂いたので整理も兼ねて発信します。
メッセージ
もっと、ＤＢの制約は使っていきましょう
前提
一番大事なことは正しいデータがＤＢに保存されていること
アプリケーションは三層構造アプリケーション
例）React → Webアプリケーション → データベース
フロントエンドで入力チェック
チェックの目的
- レスポンシビリティ、ユーザービリティ
利用者に可能な限り早くにエラーの内容を伝える - リソース節約
ネットワークリソースの節約
サーバーアプリケーションリソースの節約
チェックの内容
- 必須チェック
- 桁数チェック
- 文字列チェック
あまりやるべきではないチェック
- ＤＢの参照が必要なチェック
- 業務要件を満たすためのチェック
- 項目同士の組み合わせチェック
その他
- 今どきはライブラリが充実しているので基本的なチェックは容易に実装が可能
- 逆に言うと、ライブラリ等で簡単に実装できる範囲に留めたい
- ゴリゴリなチェックロジックは無理して実装しない
バックエンドプログラムの入力チェック
チェックの目的
- フロントエンド、ＤＢでできないチェック
- ゴリゴリなロジックが必要な際は、アプリケーションで実装
- 詳細なＡＰＩレスポンスを返却するためのチェックロジック
例えば、BadRequestをレスポンスとして返却するなら、ロジックが必要
チェックの内容
- 要はフロントエンドで入力チェックでやらないこと
- ＤＢの参照が必要なチェック
- 業務要件を満たすためのチェック
- 項目同士の組み合わせチェック
その他
- 一番工数の調整がしやすい。
- 極論、フロントエンドとＤＢの入力チェックが完璧なら何もしなくてよい
- プロジェクトマネジメントという観点では、優先順位が低いチェックロジック
- アプリケーションの本質であるビジネスロジック的なチェックは実装したい
ＤＢの入力チェック（データ制約）
チェックの目的
- データの完全性の担保
チェックの内容
- 必須チェック
- 桁数チェック
- 文字列チェック
- 親子テーブルの依存関係
あまりやるべきではないチェック
- 業務要件を満たすためのチェック
- 項目同士の組み合わせチェック
- 変更が多いチェック
その他
- 確実なチェックができる
- だけどあまり利用されないことが多い
- 基本的な制約でできることは積極的にやりたい
- ゴリゴリなチェックロジックは無理して、実装しない
- ストアドプロシージャ－や関数等は利用しない方がよい
- 特定のDBMSの機能は利用しない方がよい
総論
- チェックロジックは重複して実装してもよい
- ロジックの配置の優先順位は「ＤＢ → フロントエンド → アプリケーション」
- 謝って不正なデータを登録するよりは、謝って正しいデータが登録されない状況の方がマシ
- フロントエンドとＤＢのチェックに工数はかけない
実装をしない。という意味ではなく、不確実性の高い無理な実装はしない。という意味です。基本的なライブラリや機能を利用すれば、プロジェクト遅延の原因にはならないです。
愚痴（あとがき）
ＤＢの制約を利用を提案すると、エンジニアに拒否されることが経験では、多いです。
結果、フロントエンドのチェックとバックエンドプログラムで実装します。
拒否の理由としては、学習コストや保守性、工数です。
今回の記事は、拒否に対するアンサーとしての意味もあります。
学習コストと保守性は、「ゴリゴリなチェックロジックは無理して実装しない」で対処しています。
そもそも、学習コストは、バックエンドプログラムとＤＢ制約も、変わらないと思います。
保守性は、ロジックの重複や点在が具体的な理由です。
これも、フロントエンドとバックエンドプログラムで重複、点在しているので論理性に欠けます。
システムエンジニアリングは、様々な技術を組み合わせることが仕事だと考えています。
工数については、どうでしょうか。バックエンドプログラムでの実装とＤＢ
制約は、ＤＢ制約の方が工数としては有利だと思います。定義だけなので。
以上、後味悪いあとがきでした。忌憚ないご意見頂ければと思います。