Blazor から DB を直接叩かない、というだけで品質が安定した話

なぜ書いたか

Blazor Serverで開発していると、コンポーネントの中から DbContext を直接呼べてしまいます。最初は「画面とDBの距離が近くて速い」と思ったんですが、移行後半で 業務判定が画面側にもAPI側にも散らばって 整合が取れなくなり、結局API経由に統一しました。今回はその話です。

やったこと

ルールはひとつだけです。

Blazor側からはAPI経由でしかDBに触らない。

具体的には：

• API: 業務判定（権限、状態遷移、整合性）を全部こちらで持つ
• APIのサービス層: DBアクセス、Oracle関数呼び出し、SQL組み立てもここに集約
• Blazor側のサービス: APIを叩くHTTPクライアントとして薄く保つ
• Blazorのコンポーネント: 表示と入力制御に集中。業務判定は持たない

業務判定がAPI側に集約されていれば、UIの見た目を変えても業務同等性が崩れません。これが本当に効きました。

何が変わったか

API境界を守るようにしてから、3つのコストが下がりました。

• 業務同等性のレビュー: 業務判定がAPI側にあるので、レビュー対象が絞られる
• テスト: API側を単体テストでカバーしやすい。UIを絡めない
• 権限制御の二重化: UIとAPIの両方に同じ判定があれば良い、という構造が単純になる（二重防御の話）

わかったこと

• AIに「画面とDBを直結させて」と頼むと、最初は速い。でも5画面10画面と増えると、業務判定が散乱して同等性が崩れます
• 「API経由で触る」を デフォルトのルール にしておくと、AIもそれに従って書いてくれます。最初に明示的にルール化しないと、近道を選びがち
• DB直結が許される例外は、ごく狭いほうが良い。例外は「読み取り専用の表示専用クエリで、業務判定が一切絡まないもの」だけ、くらいに絞りました

関連する話

API境界の話は、画面ごとに「同じ業務判定が画面側とAPI側にダブって書かれている」問題ともつながります。私の場合は「業務判定はAPI側」「UIの表示制御はBlazor側」の責務分担を明示することで、ダブり実装を1箇所に寄せました。

次にやること / 未解決の問題

• API側に集約した業務判定の単体テストカバレッジが、まだ画面ごとにムラがある。最低ラインを決めたい
• 表示専用クエリの「DB直結を許す例外」をどこに線を引くかは、画面ごとにケースバイケースで判断している。ルール化したい